CVE-2026-46132

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 ifla_vf_broadcast vf_broadcast;

The struct contains a single fixed 32-byte field:

/* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast {
    __u8 broadcast[32];
};

The function then copies dev->broadcast into it using dev->addr_len as the length:

memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);

On Ethernet devices (the overwhelming majority of SR-IOV NICs) dev->addr_len 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:

nla_put(skb, IFLA_VF_BROADCAST,
    sizeof(vf_broadcast), &vf_broadcast)

leaking up to 26 bytes of uninitialised kernel stack per VF per RTM_GETLINK 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. vf_broadcast 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.