CVE-2026-53362

What it actually does

This is a Linux kernel IPv6 memory-corruption flaw in the UDPv6 send path. In __ip6_append_data(), the paged-allocation path can miscalculate skb linear and paged buffer lengths when a non-zero IPv6 fragmentation gap is carried into a subsequent socket buffer. An unprivileged local user can trigger the vulnerable path using a UDP IPv6 socket with MSG_MORE and MSG_SPLICE_PAGES, causing bytes to be copied past skb->end into skb_shared_info. The most likely immediate impact is a kernel crash or network-stack instability; depending on kernel build, allocator state, and exploit reliability, kernel memory corruption may also create a path toward local privilege escalation.

Why it matters to the business

A local user or compromised low-privilege process may be able to crash affected Linux systems and potentially escalate privileges. This is most concerning for multi-user Linux servers, container hosts, build workers, CI runners, bastion hosts, and shared application platforms where untrusted or semi-trusted code can run. The vulnerability is not currently listed in CISA KEV, is not reported as ransomware-used, has low EPSS probability, and has no stated public exploit maturity, so urgency is lower than actively exploited internet-facing issues; however, kernel memory corruption should still be prioritized because a single local foothold could threaten host stability and tenant isolation.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user or inside a workload that can create IPv6 UDP sockets and issue relevant send operations. The attacker opens a UDPv6 socket and sends data in a pattern that causes IPv6 fragmentation accounting to carry a non-zero fraggap into a later socket buffer. By combining MSG_MORE with MSG_SPLICE_PAGES and sending data large enough to take the paged-allocation branch, the kernel computes an undersized linear allocation and an overstated paged length. The fraggap bytes are then copied past the intended end of the skb linear area and into skb_shared_info. In a simple attack this can crash the kernel, producing a denial of service. A more advanced attacker would attempt to shape heap state and network-buffer layout so the overwrite corrupts useful kernel metadata, potentially converting the bug into local privilege escalation.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the fix for the IPv6 __ip6_append_data() fraggap accounting issue. Because no exact affected or fixed package versions were provided, use distribution security advisories and kernel changelogs to identify the corrected kernel for each platform. The fix adjusts the paged-allocation path so alloclen accounts for fraggap and pagedlen is reduced accordingly, and removes the MSG_SPLICE_PAGES exception from the negative-copy check. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, isolating or draining multi-tenant workloads from vulnerable hosts, restricting container capabilities where feasible, applying seccomp policies that limit unusual send/splice behavior for untrusted workloads, and disabling IPv6 only where operationally safe and explicitly approved. Reboot into the patched kernel after installation; merely installing the package is insufficient if the old kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build containing the vendor fix. Validate by checking distribution security advisories, package changelogs, or source patches for the IPv6 __ip6_append_data() fraggap accounting change in net/ipv6/ip6_output.c. On source-based validation, the paged-allocation path should include fraggap in the linear allocation calculation and subtract it from the paged length. After patching and rebooting, verify `uname -r` matches the fixed kernel package. Review kernel logs for new Oops, panic, KASAN, or networking stack warnings after update. If a safe internal reproducer exists, run it only on isolated test systems before and after patching to confirm the vulnerable kernel crashes or reports memory corruption while the fixed kernel does not.

Typical attack path

1. Obtain local execution as an unprivileged user or inside a container/workload on an affected Linux kernel.
2. Confirm IPv6 and UDPv6 socket creation are available.
3. Create a UDPv6 socket and prepare data sent using MSG_MORE so multiple skb fragments are built.
4. Use MSG_SPLICE_PAGES or a splice-backed send path with sufficiently large data to force the paged-allocation branch in __ip6_append_data().
5. Trigger a condition where fraggap is non-zero on a subsequent skb, causing the vulnerable length-accounting mismatch.
6. Cause an out-of-bounds write into skb_shared_info.
7. Use the resulting corruption to crash the host or attempt kernel control-flow/data-structure corruption for privilege escalation.

How to detect it

Look for evidence of local triggering rather than remote network scanning, because exploitation requires local code execution. Primary log sources are kernel logs, system journal, crash dumps, hypervisor or host watchdog events, endpoint telemetry for unusual local networking syscalls, and container runtime audit logs. Search for kernel Oops, panic, BUG, KASAN, UBSAN, or slab corruption messages with stack traces that include IPv6 UDP send functions such as __ip6_append_data, ip6_append_data, udp_v6_sendmsg, inet6_sendmsg, or skb-related corruption. Pay particular attention to crashes caused by unprivileged users, containers, CI jobs, or recently introduced binaries that create UDPv6 sockets and use splice/sendmsg-like behavior. If audit or eBPF telemetry captures syscall arguments, hunt for processes repeatedly using sendmsg/sendmmsg with MSG_MORE and MSG_SPLICE_PAGES on AF_INET6 SOCK_DGRAM sockets shortly before a crash. Absence of these artifacts does not prove non-exploitation because successful memory corruption may produce generic crashes or no durable logs.

• __ip6_append_data
• ip6_append_data
• udp_v6_sendmsg
• inet6_sendmsg
• MSG_SPLICE_PAGES
• MSG_MORE
• KASAN: slab-out-of-bounds
• KASAN: use-after-free
• BUG: unable to handle page fault
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at net/ipv6/ip6_output.c
• skb_shared_info
• skb_over_panic
• skbuff: skb_over_panic

What your security team should do

• Prioritize patching shared Linux systems, container hosts, CI/build infrastructure, bastion servers, and any host where untrusted users can run local code.
• Inventory Linux kernels across fleets and map them to vendor advisories for this issue, since exact fixed versions vary by distribution and kernel branch.
• Reboot systems after kernel updates and verify the running kernel version is the fixed version.
• Increase monitoring for kernel crashes, Oops reports, KASAN findings, and stack traces involving IPv6 UDP send paths until patch coverage is complete.
• Where patching is delayed, reduce local attack surface by limiting untrusted interactive access and tightening container/seccomp policies for workloads that do not need advanced splice/send behavior.
• Do not treat the low EPSS score as a reason to ignore the issue on multi-tenant hosts; local kernel memory corruption can materially affect host isolation and availability.