CVE-2026-43040

What it actually does

This Linux kernel flaw can disclose small amounts of uninitialized kernel memory when IPv6 Router Advertisement user options are converted into RTM_NEWNDUSEROPT netlink messages. The kernel structure used for the notification contains padding fields that were not zeroed before being sent to user space, allowing a local low-privileged process that can receive the relevant netlink messages to observe residual kernel stack or heap data. The direct impact is confidentiality loss; the leaked data may help bypass kernel hardening such as address randomization or expose fragments of sensitive kernel memory depending on what was present in the padding bytes.

Why it matters to the business

Systems running affected Linux kernels may unintentionally expose kernel memory contents to local users or processes. On shared Linux servers, container hosts, developer workstations, appliances, or multi-user systems, this can aid privilege-escalation chains by giving attackers information needed to defeat exploit mitigations. The EPSS score is currently low, there is no known CISA KEV listing, no known ransomware use, and no public exploit maturity reported, so this is not currently a mass-exploitation emergency; however, kernel information leaks should still be remediated through normal kernel update cycles because they are often valuable as part of multi-stage attacks.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged or low-privileged local user on an affected Linux system. The attacker then arranges to receive netlink route notifications related to IPv6 Neighbor Discovery user options, and either waits for or induces IPv6 Router Advertisement processing that causes the kernel to build an RTM_NEWNDUSEROPT message. Because the vulnerable kernel does not initialize the padding fields in the nduseroptmsg structure, the netlink message returned to user space can contain leftover kernel memory bytes. The attacker repeatedly collects these messages and analyzes the leaked bytes for useful kernel pointers, memory layout hints, or sensitive fragments. The leak is most useful when combined with another kernel bug that requires defeating address-space randomization or other exploitation defenses.

How to fix it

Upgrade to a Linux kernel package from the relevant distribution or vendor that includes the fix for the IPv6 Neighbor Discovery nduseroptmsg padding initialization issue. Because no exact fixed versions were provided, use vendor advisories and package changelogs to identify the first kernel build containing the patch that zeroes the nduseropt_pad fields in ndisc_ra_useropt processing. After installing the updated kernel, reboot the system so the fixed kernel is active. Where IPv6 Router Advertisements are not required, reduce exposure by disabling IPv6 RA acceptance on applicable interfaces using sysctls such as net.ipv6.conf.<interface>.accept_ra=0 or net.ipv6.conf.all.accept_ra=0, while validating that this does not disrupt legitimate network configuration. On multi-user systems, reduce local attack surface by limiting untrusted shell access and applying least privilege to workloads.

How to confirm the fix worked

Confirm the running kernel is the remediated vendor build, not merely that an updated package is installed. Check the active kernel with uname -r, verify the installed package version against the vendor security advisory, and review distro changelogs for references to IPv6 Neighbor Discovery, ndisc_ra_useropt, nduseroptmsg, RTM_NEWNDUSEROPT, or initialization of nduseropt_pad fields. If building kernels internally, confirm the source initializes the padding fields to zero before sending RTM_NEWNDUSEROPT messages. Validate mitigations by checking IPv6 RA acceptance settings with sysctl net.ipv6.conf.all.accept_ra and per-interface accept_ra values. For high-assurance validation, run a lab test that triggers IPv6 Router Advertisement user option handling and confirms the resulting netlink message padding bytes are consistently zeroed on the patched kernel.

Typical attack path

1. Gain local code execution or low-privileged shell access on an affected Linux host.
2. Open or monitor NETLINK_ROUTE netlink communications capable of receiving IPv6 Neighbor Discovery user option notifications.
3. Trigger or wait for IPv6 Router Advertisements containing user options to be processed by the kernel.
4. Collect RTM_NEWNDUSEROPT messages generated by the kernel.
5. Extract uninitialized padding bytes from the nduseroptmsg data returned to user space.
6. Repeat collection to obtain enough leaked data for memory disclosure, kernel address discovery, or exploit-development support.
7. Use the disclosed kernel information to assist a separate privilege-escalation or sandbox/container escape technique.

How to detect it

There is typically no definitive log entry showing exploitation because the leak occurs inside kernel-to-user-space netlink message contents and may not be recorded by default. To assess possible prior exploitation, review auditd, eBPF, Sysmon for Linux, or EDR telemetry for unusual local processes opening NETLINK_ROUTE sockets, subscribing to route or Neighbor Discovery netlink groups, or repeatedly invoking tools that monitor IPv6 neighbor discovery events. Review packet captures, network sensor logs, or switch RA-Guard telemetry for unexpected ICMPv6 Router Advertisement traffic, especially on server VLANs where RAs should only come from known routers. On hosts with process accounting, look for suspicious use of commands such as ip -6 monitor, ss, custom netlink tooling, fuzzers, or exploit-development binaries near times when unexpected Router Advertisements were observed. Kernel logs are unlikely to contain evidence unless additional debugging or auditing was enabled. Treat detections as suspicious rather than conclusive, and combine host process telemetry with network RA observations and any signs of follow-on local privilege escalation.

• RTM_NEWNDUSEROPT
• nduseroptmsg
• ndisc_ra_useropt
• NETLINK_ROUTE
• socket(AF_NETLINK
• NETLINK_ADD_MEMBERSHIP
• ip -6 monitor
• ip monitor all
• ICMPv6 Router Advertisement
• icmp6 type 134
• net.ipv6.conf.all.accept_ra
• net.ipv6.conf.default.accept_ra

What your security team should do

• Prioritize patching shared Linux servers, container hosts, virtualization hosts, bastion systems, and any multi-user environments where untrusted local users or workloads may execute code.
• Apply vendor kernel updates that include the nduseroptmsg padding initialization fix and reboot promptly to activate the fixed kernel.
• If IPv6 Router Advertisements are unnecessary on servers, disable RA acceptance on those interfaces after confirming operational impact.
• Inventory Linux systems with IPv6 enabled and identify hosts running kernels older than the vendor-fixed build.
• Treat this vulnerability as a useful exploit-chain primitive: correlate with other local privilege-escalation findings and prioritize hosts that also have unpatched kernel memory-corruption bugs.
• Monitor for unusual local processes interacting with NETLINK_ROUTE and for unexpected IPv6 Router Advertisements on networks where router advertisements should be controlled.
• Because EPSS is low and there is no KEV or ransomware association, handle through expedited routine patch management rather than emergency incident response unless suspicious local activity is observed.