SEC.co
Emergency
MEDIUM 5.5

CVE-2026-46132

CVE-2026-46132 is a kernel memory leak in the Linux networking subsystem that allows unprivileged local users to read up to 26 bytes of uninitialized kernel stack memory per virtual function (VF) per request. The vulnerability exists in the rtnetlink interface handler that reports virtual NIC configuration. When a user requests virtual function information, the kernel fails to zero-initialize a buffer before partially filling it with MAC broadcast data, leaving residual stack contents exposed to userspace. An attacker needs only basic local network namespace access to trigger repeated information leaks.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-908
Affected products
3 configuration(s)
Published / Modified
2026-05-28 / 2026-06-24

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo rtnl_fill_vfinfo() declares struct ifla_vf_broadcast 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, vf_vlan_info, node_guid and port_guid a few lines above. vf_broadcast was simply missed when it was added. Reachability: any unprivileged local process can open AF_NETLINK / NETLINK_ROUTE without capabilities and send RTM_GETLINK with an IFLA_EXT_MASK attribute carrying RTEXT_FILTER_VF. The kernel walks each VF and emits IFLA_VF_BROADCAST, 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 nla_put() 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.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability resides in rtnl_fill_vfinfo() within the rtnetlink subsystem. The function declares a stack-allocated struct ifla_vf_broadcast containing a 32-byte broadcast array, but does not initialize it before use. The function then copies dev->broadcast into this array using dev->addr_len (typically 6 bytes for Ethernet devices) as the copy length via memcpy(). This leaves 26 bytes uninitialized. The entire struct is subsequently passed to userspace via nla_put(), exposing the uninitialized stack memory. The reachability vector is straightforward: any unprivileged process can open an AF_NETLINK socket with NETLINK_ROUTE protocol and issue RTM_GETLINK requests with RTEXT_FILTER_VF flags, triggering the leak for each configured VF. The fix involves zero-initializing the struct before the partial memcpy(), following the pattern already used for other vf_* structures in the same function (ivi, vf_vlan_info, node_guid, port_guid).

Business impact

This vulnerability poses a localized information disclosure risk primarily relevant to multi-tenant or shared-kernel environments. Systems that isolate user namespaces or heavily restrict netlink access face reduced exposure. The leaked kernel stack data could potentially include return addresses, function pointers, or transient sensitive information depending on kernel build configuration and runtime state. For organizations running container platforms, shared hosting, or research environments on Linux SR-IOV infrastructure, this represents a confidentiality breach avenue. The low privilege requirement (unprivileged local process) and repeatability make it suitable for reconnaissance in privilege escalation chains, though the direct business impact is limited to information leakage rather than system compromise.

Affected systems

Linux kernel versions containing the vulnerable rtnl_fill_vfinfo() implementation are affected. The vulnerability applies to any kernel build with SR-IOV (Single Root I/O Virtualization) VF support enabled and network interface SR-IOV virtual functions configured. Practical impact is highest on systems running virtual machines or containers with SR-IOV pass-through NICs. Standard Ethernet devices are the primary vector (dev->addr_len = 6), though the vulnerability generalizes to any device type where addr_len < 32. Verify the specific affected versions against the Linux kernel security advisories and your distribution's backport status.

Exploitability

Exploitability is straightforward and requires minimal privileges. An unprivileged local process can repeatedly invoke the leak by: (1) opening a NETLINK_ROUTE socket (no capabilities required), (2) sending RTM_GETLINK netlink messages with IFLA_EXT_MASK set to include RTEXT_FILTER_VF, and (3) receiving kernel stack bytes in the response for each configured VF. No race conditions, timing windows, or kernel memory layout knowledge is necessary. The leak is deterministic and repeatable on demand, making it a reliable reconnaissance tool. Mitigation via network namespace isolation or restrictive AppArmor/SELinux policies can reduce exposure, but the attack surface is fundamentally native to the netlink interface design.

Remediation

The fix is a single initialization step: zero the on-stack ifla_vf_broadcast struct using memset() before the partial memcpy(), consistent with the pattern applied to other vf_* structs in the same function. This is a minimal, low-risk patch that incurs negligible performance impact. Vendors and distribution maintainers should apply the fix to affected kernel versions and backport it through their supported release branches. Kernel builds without SR-IOV support or with minimal VF configuration face reduced practical risk but should still receive the patch for defense-in-depth.

Patch guidance

Apply the fix from the upstream Linux kernel repository once it is released in a stable kernel version. Monitor your Linux distribution's security advisories for backported patches to your supported kernel branches. Verify patch application by confirming the ifla_vf_broadcast struct is zero-initialized before memcpy() in rtnl_fill_vfinfo(). If custom kernel builds are maintained, apply the patch directly to your source tree and recompile. Test in a staging environment to validate the fix does not introduce regressions in VF reporting via rtnetlink (e.g., ip link show with VF enumeration).

Detection guidance

Detection of exploitation is challenging because the attack uses standard netlink API calls that appear benign in isolation. Detect patterns via: (1) netlink auditing rules monitoring RTM_GETLINK messages with RTEXT_FILTER_VF flags from unprivileged processes, especially if repeated in short intervals; (2) KASAN or KMSAN kernel instrumentation, which will flag uninitialized memory access at the nla_put() call during reproduction; (3) monitoring unprivileged netlink socket creation and RTM_GETLINK issuance via seccomp or eBPF. Retrospective detection from userspace is impractical—the leaked data appears as normal netlink response traffic. Kernel-level instrumentation is the most reliable detection method.

Why prioritize this

Although the CVSS score is 5.5 (medium), this vulnerability should be prioritized based on ease of exploitation and low barrier to entry. Any unprivileged local user can trigger the leak without special tools, privileges, or kernel knowledge, making it a high-volume reconnaissance vector in shared environments. The repeatability and determinism differentiate it from transient memory leaks. Organizations running container platforms, shared hosting, or multi-tenant Kubernetes clusters should treat this as high priority for patch deployment. Single-tenant systems with strong user/kernel isolation policies can deprioritize but should not ignore it indefinitely.

Risk score, explained

The CVSS 3.1 score of 5.5 reflects the vulnerability's local attack vector (AV:L), low privilege requirement (PR:L), lack of user interaction (UI:N), and absence of scope change (S:U). The score emphasizes the denial-of-service avenue (A:H) over the information disclosure, which is atypical for leak vulnerabilities. However, the practical risk is arguably higher than the score suggests: information leakage is repeatable and deterministic, the privilege bar is very low, and the attack surface is broad in multi-tenant environments. Use CVSS as a baseline but weight local context (namespace isolation, netlink restrictions) and asset criticality when making remediation decisions.

Frequently asked questions

Can an attacker exploit this vulnerability without local system access?

No. This vulnerability requires unprivileged local process access to the system, typically via a user account or container. Remote attackers cannot trigger the leak directly over the network, though compromised accounts or escaped containers could be exploitation vectors.

What kinds of sensitive data might be leaked from kernel stack memory?

The leaked 26 bytes are kernel stack residue and may include return addresses, function pointers, other uninitialized struct fields, or transient sensitive data left on the stack by prior kernel functions. The exact content depends on kernel build configuration, runtime state, and what functions executed before rtnl_fill_vfinfo(). While not guaranteed to leak cryptographic keys or credentials, the information can assist privilege escalation reconnaissance.

Does this vulnerability affect systems without SR-IOV virtual functions configured?

The vulnerability exists in the code path regardless, but it is only triggered when at least one VF is configured and a user requests VF information via RTM_GETLINK with RTEXT_FILTER_VF. Systems with SR-IOV disabled or no VFs provisioned are not practically exploitable, but they still carry the vulnerable code.

What is the performance impact of the fix?

Negligible. The fix adds a single memset() call to zero the struct on the stack, which is a trivial operation. There is no algorithmic change, no additional system calls, and no impact on the netlink response or datapath performance.

This analysis is based on the CVE-2026-46132 public advisory and is accurate as of the publication date. Readers must verify affected kernel versions, patch availability, and applicability to their specific systems by consulting the Linux kernel security repository and their distribution maintainers' advisories. No liability is assumed for remediation decisions based on this content. Organizations should conduct their own risk assessment in the context of their infrastructure, isolation policies, and threat model before determining patch priority. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).

Affected vendors

linux

Weaknesses (CWE)

CWE-908

Related vulnerabilities