CVE-2026-46132: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
In the Linux kernel, the following vulnerability has been resolved:
net: rtnetlink: zero iflavfbroadcast to avoid stack infoleak in rtnlfillvfinfo
rtnlfillvfinfo() declares struct iflavfbroadcast on the stack without initialisation:
struct iflavfbroadcast vfbroadcast;
The struct contains a single fixed 32-byte field:
/ include/uapi/linux/iflink.h / struct iflavfbroadcast { u8 broadcast[32]; };
The function then copies dev->broadcast into it using dev->addrlen as the length:
memcpy(vfbroadcast.broadcast, dev->broadcast, dev->addrlen);
On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addrlen is 6, so only the first 6 bytes of broadcast[] are written. The remaining 26 bytes retain whatever was previously on the kernel stack. The full struct is then handed to userspace via:
nlaput(skb, IFLAVFBROADCAST, sizeof(vfbroadcast), &vfbroadcast)
leaking up to 26 bytes of uninitialised kernel stack per VF per RTMGETLINK request, repeatable.
The other vf structs in the same function are explicitly zeroed for exactly this reason - see the memset() calls for ivi, vfvlaninfo, nodeguid and portguid a few lines above. vfbroadcast was simply missed when it was added.
Reachability: any unprivileged local process can open AFNETLINK / NETLINKROUTE without capabilities and send RTMGETLINK with an IFLAEXTMASK attribute carrying RTEXTFILTERVF. The kernel walks each VF and emits IFLAVFBROADCAST, leaking 26 bytes of stack per VF per request. Stack residue at this call site can include return addresses and transient sensitive data; KASAN with stack instrumentation, or KMSAN, will flag the nlaput() when reproduced.
Zero the on-stack struct before the partial memcpy, matching the existing pattern used for the other vf structs in the same function.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.141.1-1
Event History
Frequently Asked Questions
Who can retrieve the leaked data?
The issue requires local access and low privileges. A local user able to issue RTM_GETLINK requests can receive the IFLA_VF_BROADCAST attribute containing uninitialised kernel-stack bytes.
Which network devices are most likely to expose data?
Ethernet devices are the primary concern because their address length is typically 6 bytes. The 32-byte broadcast field is then only partially populated, leaving up to 26 bytes of stack data exposed for each VF.
Can the disclosure be repeated?
Yes. The leak occurs per VF per RTM_GETLINK request and is described as repeatable, allowing repeated retrieval attempts of uninitialised stack contents.
How can I determine whether a kernel contains the vulnerable behavior?
Check whether rtnl_fill_vfinfo() declares ifla_vf_broadcast on the stack and copies only dev->addr_len bytes into its 32-byte broadcast field without first zeroing the structure. A corrected implementation zeroes the structure before it is supplied through IFLA_VF_BROADCAST.