CVE-2026-63920

What it actually does

This Linux kernel flaw is a local information disclosure and stability issue in IPv6 ancillary data handling. The kernel trusted the IPv6 extension-header length byte when building control messages returned to userspace by recvmsg(). A local attacker who can use nftables from an unprivileged user namespace can rewrite the extension-header length after initial packet parsing, causing put_cmsg() to read beyond the actual 8-byte header and copy adjacent slab memory into userspace or trigger a kernel memory-safety fault. The impact is primarily disclosure of kernel heap contents, with potential denial of service through kernel crash or KASAN-detected slab out-of-bounds access.

Why it matters to the business

Systems that allow unprivileged user namespaces and nftables access may let a local low-privileged user or compromised application read sensitive kernel memory or crash the host. This can increase the impact of an initial foothold on shared Linux servers, container hosts, developer workstations, CI runners, and multi-tenant systems. The vulnerability is not listed in CISA KEV, has low EPSS, and no known mature public exploitation is indicated, but kernel-local privilege-boundary issues should still be prioritized on systems where untrusted users or containers can run code.

How an attack unfolds

An attacker first obtains the ability to execute local code as an unprivileged user. They create or enter a user namespace where nftables operations are permitted, then configure an nftables payload-write rule that modifies the IPv6 extension-header hdrlen byte after the kernel has parsed the packet but before userspace receives ancillary data through recvmsg(). The attacker sends or loops IPv6 traffic containing extension headers such as Hop-by-Hop, Destination Options, or Routing headers to a socket configured to receive the corresponding IPv6 control messages. When the vulnerable recvmsg() path builds IPV6_HOPOPTS, IPV6_DSTOPTS, IPV6_RTHDR, or legacy IPV6_2292* control messages, it uses the attacker-modified hdrlen value and reads beyond the real extension header. Depending on memory layout and kernel hardening, the attacker may receive leaked slab bytes in userspace or cause a kernel warning, oops, or crash.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the fix for IPv6 extension-header length validation before copying extension headers into control messages. Because no product-specific fixed versions were provided, use the latest patched kernel from the operating-system vendor or distribution security channel and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, restricting unprivileged nftables/netfilter access, limiting local shell access on shared systems, and applying container hardening that prevents CAP_NET_ADMIN and nftables manipulation in untrusted workloads. Monitor vendor advisories for exact package versions for each distribution kernel branch.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the upstream fix that validates IPv6 extension-header length with bounds checks before put_cmsg() processing. Validate by checking distribution security advisories and installed kernel package changelogs for the IPv6/ip6_datagram_recv_specific_ctl() fix. After patching, reboot and verify the active kernel version with uname -r and package-manager inventory. For exposure validation, identify systems with IPv6 enabled, unprivileged user namespaces enabled, and nftables available to untrusted users or containers. Defensive testing should be performed only in isolated labs because proof-of-concept behavior may crash vulnerable kernels.

Typical attack path

1. Gain local code execution as a low-privileged user or inside a container/user namespace.
2. Create or use an unprivileged user namespace with access to nftables/netfilter operations.
3. Install an nftables rule using a payload-write expression that rewrites the IPv6 extension-header length byte after packet parsing.
4. Generate IPv6 packets with extension headers such as Hop-by-Hop, Destination Options, or Routing headers.
5. Open an IPv6 UDP/raw socket configured to receive IPv6 ancillary control messages.
6. Call recvmsg() so the kernel builds IPv6 extension-header control messages using the corrupted hdrlen value.
7. Read leaked kernel slab memory from returned control-message data or trigger a kernel out-of-bounds read/crash.

How to detect it

Successful exploitation is local and may leave limited network evidence because the trigger can be generated on-host. Focus on host telemetry. Review kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, and crash dumps for slab out-of-bounds reads or kernel oops traces involving put_cmsg(), udpv6_recvmsg(), sock_recvmsg(), recvmsg(), and IPv6 extension-header control messages. Look for KASAN reports if debug kernels are used. Correlate kernel faults with recent creation of user namespaces, nftables rule changes, unprivileged use of nft, and suspicious local processes generating IPv6 traffic. Audit logs may show execution of nft, unshare, nsenter, ip, or custom binaries by non-root users. In containerized environments, review workloads that were granted CAP_NET_ADMIN or otherwise allowed netfilter/nftables manipulation. Network monitoring may show unusual local or host-originated IPv6 packets with Hop-by-Hop, Destination Options, or Routing extension headers, but absence of such telemetry does not rule out exploitation.

• BUG: KASAN: slab-out-of-bounds in put_cmsg
• put_cmsg+0x3ac/0x540
• udpv6_recvmsg+0xca0/0x1250
• sock_recvmsg+0xdf/0x190
• ____sys_recvmsg+0x1b1/0x620
• ip6_datagram_recv_specific_ctl
• IPV6_HOPOPTS
• IPV6_DSTOPTS
• IPV6_RTHDR
• IPV6_2292HOPOPTS
• IPV6_2292DSTOPTS
• IPV6_2292RTHDR
• nft add rule
• nft -f
• unshare --user
• unshare -Ur
• kernel: BUG: KASAN: slab-out-of-bounds
• kernel: general protection fault
• kernel: kernel BUG at
• kernel: Oops

What your security team should do

• Prioritize patching shared Linux hosts, container platforms, CI runners, bastion systems, and any servers where untrusted local users can execute code.
• Inventory kernels across Linux fleets and map them to vendor advisories for this IPv6 extension-header validation fix.
• Temporarily disable or restrict unprivileged user namespaces on high-risk systems if compatible with workloads.
• Ensure untrusted containers do not receive CAP_NET_ADMIN and cannot manipulate nftables rules.
• Monitor kernel logs for KASAN, BUG, oops, or panic messages involving put_cmsg(), udpv6_recvmsg(), or ip6_datagram_recv_specific_ctl().
• Review recent local-user activity and container workloads on systems that show matching kernel memory-safety faults.
• Treat any confirmed crash or slab out-of-bounds read evidence as potential local exploitation and preserve kernel logs, audit logs, container metadata, and shell histories for investigation.