CVE-2026-46132

What it actually does

This is a local Linux kernel information disclosure flaw in the rtnetlink code path used to report SR-IOV virtual function metadata. When handling an RTM_GETLINK request with the RTEXT_FILTER_VF extension filter, rtnl_fill_vfinfo() places an ifla_vf_broadcast structure on the kernel stack and copies only dev->addr_len bytes of the device broadcast address into its 32-byte field. For typical Ethernet devices, only 6 bytes are initialized and the remaining 26 bytes can contain stale kernel stack data. The full 32-byte structure is then copied to user space in the IFLA_VF_BROADCAST netlink attribute. An unprivileged local process can repeatedly trigger this path through NETLINK_ROUTE and potentially collect kernel stack residue, which may aid other exploitation by exposing addresses or transient sensitive values.

Why it matters to the business

The primary risk is that a local user or compromised low-privilege process can extract small amounts of kernel memory from systems with affected kernel code, especially where SR-IOV-capable networking is present. By itself, this is not a remote network compromise, but it can weaken kernel hardening, assist privilege-escalation chains, and increase risk on multi-user servers, virtualization hosts, container platforms, and network-intensive infrastructure. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so remediation should be prioritized based on exposure of multi-tenant or untrusted local workloads rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first obtains the ability to run code locally as an unprivileged user, for example through a shell account, compromised application process, container escape staging context, or post-exploitation foothold. The attacker opens an AF_NETLINK socket using the NETLINK_ROUTE protocol and sends RTM_GETLINK requests that include an IFLA_EXT_MASK attribute with RTEXT_FILTER_VF set. On affected kernels, the rtnetlink handler walks virtual function information for network devices and emits IFLA_VF_BROADCAST attributes. Because the kernel stack structure used for this attribute was not fully initialized before being copied into the netlink response, each response can disclose up to 26 bytes of stale kernel stack data per VF. The attacker repeats the request many times, collects leaked bytes, and analyzes them for useful values such as kernel pointers, stack layout hints, or other transient data that may help bypass mitigations or support a separate local privilege-escalation exploit.

How to fix it

Upgrade to a Linux kernel build that includes the fix for rtnetlink zero-initializing the ifla_vf_broadcast stack structure before copying the device broadcast address. No exact fixed package versions were provided in the input, so use vendor advisories for the deployed distribution or kernel source tree and install the first kernel package that explicitly includes the rtnetlink IFLA_VF_BROADCAST stack initialization fix. Reboot into the updated kernel after patching; merely installing the package is not sufficient if the old kernel remains running. Where immediate patching is not possible, reduce risk by limiting local shell access, avoiding untrusted workloads on affected hosts, hardening container boundaries, disabling or restricting SR-IOV virtual function exposure where operationally feasible, and using kernel hardening features such as KASLR and unprivileged user restrictions. Mitigations should not be considered equivalent to patching because the vulnerable netlink interface is normally reachable by unprivileged local processes.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, contains the vendor fix. Validate by checking the distribution kernel changelog or source patch for zero-initialization of struct ifla_vf_broadcast in rtnl_fill_vfinfo(), such as a memset() or initializer before the partial memcpy. On source-based systems, inspect net/core/rtnetlink.c and confirm vf_broadcast is cleared before nla_put() emits IFLA_VF_BROADCAST. After rebooting, verify uname -r reflects the remediated kernel version from the vendor advisory. For deeper validation in test environments, run a controlled RTM_GETLINK/RTEXT_FILTER_VF reproducer against an affected SR-IOV-capable device and confirm that bytes beyond the actual broadcast address are zeroed rather than containing variable stack residue. Kernel sanitizers such as KMSAN or KASAN with stack instrumentation can also be used in non-production testing to confirm the uninitialized copy no longer occurs.

Typical attack path

1. Gain local code execution as an unprivileged user or process on an affected Linux system.
2. Open an AF_NETLINK socket using the NETLINK_ROUTE protocol.
3. Send RTM_GETLINK messages that request extended virtual-function information by setting IFLA_EXT_MASK to include RTEXT_FILTER_VF.
4. Receive rtnetlink responses containing IFLA_VF_BROADCAST attributes for SR-IOV virtual functions.
5. Extract the uninitialized trailing bytes from the 32-byte broadcast field returned to user space.
6. Repeat the request to collect additional stack residue and analyze the data for kernel addresses or other useful values.
7. Use the disclosed information to improve reliability of a separate exploit chain or to reduce effectiveness of kernel memory disclosure mitigations.

How to detect it

Detecting prior exploitation is difficult because successful exploitation uses legitimate local netlink requests and may leave no default log entry. Focus on endpoint telemetry, audit logs, eBPF tracing, and process monitoring capable of observing AF_NETLINK/NETLINK_ROUTE socket activity and rtnetlink message types. Look for unprivileged processes repeatedly opening NETLINK_ROUTE sockets and sending RTM_GETLINK requests with IFLA_EXT_MASK including RTEXT_FILTER_VF, especially from unexpected binaries, scripts, containers, temporary directories, or low-privilege service accounts. Review kernel logs for sanitizer findings in test or debug kernels, including KMSAN/KASAN reports involving rtnl_fill_vfinfo(), nla_put(), or uninitialized memory copied to user space. In forensic triage, correlate suspicious local execution with tools or code that parse netlink attributes IFLA_VF_BROADCAST, enumerate SR-IOV VFs, or repeatedly query link metadata. Absence of logs does not prove non-exploitation unless detailed syscall/netlink telemetry was collected at the time.

• RTM_GETLINK
• IFLA_EXT_MASK
• RTEXT_FILTER_VF
• IFLA_VF_BROADCAST
• NETLINK_ROUTE
• AF_NETLINK
• rtnl_fill_vfinfo
• ifla_vf_broadcast
• nla_put
• uninitialized value in rtnl_fill_vfinfo
• KMSAN: uninit-value
• KASAN: use of uninitialized value
• net/core/rtnetlink.c

What your security team should do

• Prioritize patching multi-user Linux systems, virtualization hosts, Kubernetes/container worker nodes, CI runners, bastion hosts, and systems that allow untrusted local code execution.
• Inventory systems running affected Linux kernels and identify hosts with SR-IOV-capable NICs or virtual functions, because those systems are the most relevant exposure for this bug.
• Apply vendor kernel updates that include the rtnetlink ifla_vf_broadcast zero-initialization fix and reboot into the fixed kernel.
• Treat any local compromise on affected high-value hosts as more serious because this flaw may help attackers bypass kernel hardening when chained with other vulnerabilities.
• If patching must be delayed, restrict local user access, reduce untrusted workload placement, review container isolation controls, and disable unnecessary SR-IOV VF exposure where feasible.
• Monitor for unusual local processes repeatedly issuing rtnetlink RTM_GETLINK requests with virtual-function extension filters, especially from unexpected service accounts, containers, or temporary directories.
• Do not rely on network perimeter controls for this issue; exploitation is local and occurs through kernel netlink interfaces rather than inbound TCP/UDP services.