GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel RDMA core address resolution (RDMA_NL_LS_OP_IP_RESOLVE netlink handler): The netlink handler for

CVSS 5.5CVE-2025-71096Firmware, BMC & network fabriccurated

Impact

The netlink handler for kernel-initiated RDMA address resolution assumed userspace would always supply the destination GID attribute and never verified it. Omitting it leaves the DGID buffer uninitialized and the kernel then formats and consumes leftover stack contents as a fabric address - a KMSAN-confirmed uninitialized read whose value userspace can influence by shaping the stack beforehand. The practical worry on a shared node is not just the info leak but that a bogus DGID is what the kernel then tries to route to.

Who can reach it

Local. A userspace RDMA netlink service (the rdma-ndd / ibacm style daemon slot) replies to a kernel LS_IP_RESOLVE query without the DGID attribute. Requires the ability to bind the RDMA netlink LS service in the namespace.

What to do

Kernel update that parses the attributes with nla_parse_deprecated() and fails cleanly when DGID is absent. Verify no tenant workload can register itself as the RDMA netlink LS responder - that slot should belong to a host daemon only.

References

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b948afc1ded88b3562c893114387f34389eeb94https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2025/CVE-2025-71096.json

Related entries

All Firmware, BMC & network fabric entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.