high

CVE

CVE-2026-53362

CWE

CWE-787

Affected Surface

  • Linux kernels that still carry the vulnerable UDPv6 `__ip6_append_data()` path, including `6.1.x < 6.1.177`, `6.2.x through 6.6.143`, `6.7.x through 6.12.94`, `6.13.x through 6.18.37`, `6.19.x through 7.1.2`, and mainline before `7.2-rc1`, subject to vendor backports
  • Developer workstations, self-hosted CI runners, shared bastions, and container hosts where untrusted local code can create user or network namespaces and reach UDPv6 socket operations
  • Linux distributions and products that ship affected upstream logic, including Red Hat Enterprise Linux 10 and layered products that inherit the vulnerable kernel until vendor fixes are installed and booted
  • Container environments where a first-stage package compromise or application foothold lands inside an unprivileged Linux context but still shares the host kernel

CVE-2026-53362 is the strongest fresh /research candidate from the last three days because CISA added it to the Known Exploited Vulnerabilities catalog on 27 August 2026. The bug itself was disclosed earlier in the summer, but the KEV addition changes the priority. This is now an actively exploited Linux kernel privilege-escalation issue in the IPv6 UDP send path, and Red Hat is explicit that the real-world blast radius includes container escape and SELinux bypass.

For application-security teams, the practical point is simple. A malicious package, poisoned build step, or ordinary low-privilege shell on a Linux host does not need to start with kernel access. CVE-2026-53362 is the kind of post-foothold bug that can turn that local code execution into host root if the runner, workstation, or container host is still on a vulnerable kernel.

What changed this week

The new fact inside the last-72-hours window is exploitation priority, not just CVE metadata:

  • CISA added CVE-2026-53362 to KEV on 2026-08-27 and marked it for forensic triage.
  • Red Hat published an active-exploitation-oriented bulletin that describes the issue as ipv6_frag_escape and calls out container-to-host impact on RHEL 10 systems.
  • Stable kernel fixes were already available, so the remaining risk is mostly a patch-deployment and reboot problem, not a missing-upstream-fix problem.

That combination makes the issue worth a stand-alone article. It is no longer only a kernel-internals bug for distro teams. It is a live second-stage privilege amplifier for Linux environments that run less-trusted code.

What is affected

The vulnerable code lives in the Linux kernel’s IPv6 output path, specifically net/ipv6/ip6_output.c inside __ip6_append_data(). Public kernel metadata and machine-readable feeds agree on the first upstream fixed releases:

Upstream lineFirst fixed release
6.1.x6.1.177
6.2.x through 6.6.x6.6.144
6.7.x through 6.12.x6.12.95
6.13.x through 6.18.x6.18.38
6.19.x through 7.1.x7.1.3
mainline7.2-rc1

The public disclosure adds the trigger preconditions that matter during scoping:

local unprivileged user
-> UDPv6 socket
-> MSG_MORE
-> MSG_SPLICE_PAGES
-> datagram crosses a fragment boundary
-> controlled 15-byte OOB write into skb_shared_info

Two environment details matter a lot:

  1. The IPv6 path needs CONFIG_IPV6=y.
  2. The highest-risk container and multi-user cases are the ones that let an attacker create user or network namespaces.

Red Hat’s bulletin is useful here because it ties the bug to a realistic enterprise configuration. On RHEL 10, unprivileged user namespaces are enabled by default, which is enough to keep container-host exposure squarely in scope until patched kernels are deployed.

Root cause: fraggap was counted in the payload length, but not in the linear allocation

The kernel and oss-security write-ups are aligned on the mistake. In the paged allocation branch of __ip6_append_data(), datalen already includes fraggap, but the code allocated the new skb linear area as if those bytes did not exist:

alloclen = fragheaderlen + transhdrlen;
pagedlen = datalen - transhdrlen;

copy = datalen - transhdrlen - fraggap - pagedlen;
if (copy < 0 && !(flags & MSG_SPLICE_PAGES))
        goto error;

That arithmetic is the whole issue.

  • datalen = length + fraggap, so the carried-over bytes are already part of the new payload length.
  • alloclen forgot those same bytes, so the linear area ended up too small.
  • pagedlen overstated how much of the payload could live on the paged side.
  • copy collapsed to -fraggap.
  • The negative-copy guard was skipped when MSG_SPLICE_PAGES was set, so the kernel still copied bytes into the undersized linear area.

The result was not an off-by-one nuisance. The public disclosure says the write lands past skb->end and into trailing skb_shared_info, which is enough for a controlled 15-byte overwrite and practical local privilege escalation.

Why the MSG_SPLICE_PAGES gate mattered

The interesting detail is that the bad fraggap accounting alone was not the full story. Both the upstream patch description and the oss-security disclosure point to a second commit, ce650a166335 (udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES), as the change that made the corruption reachable.

Before that later change, the same negative copy arithmetic fell out to -EINVAL. After it, the MSG_SPLICE_PAGES case was allowed to proceed:

if (copy < 0 && !(flags & MSG_SPLICE_PAGES)) {
        err = -EINVAL;
        goto error;
}

That is why the public disclosure phrases the issue as a bug in the UDP corking path when MSG_SPLICE_PAGES is set. The exploit is not “IPv6 is unsafe” in the abstract. It is a very specific interaction between fragment-boundary carryover, paged allocation, and a condition that incorrectly exempted one negative-copy case from rejection.

The fix is small, and it lands exactly on the broken math

The upstream fix is only a few lines, but it closes the bug at the right place:

- alloclen = fragheaderlen + transhdrlen;
- pagedlen = datalen - transhdrlen;
+ alloclen = fragheaderlen + transhdrlen + fraggap;
+ pagedlen = datalen - transhdrlen - fraggap;

- if (copy < 0 && !(flags & MSG_SPLICE_PAGES)) {
+ if (copy < 0) {
        err = -EINVAL;
        goto error;
  }

The change does two things:

  1. It makes the paged branch account for fraggap the same way the non-paged branch already did.
  2. It removes the special-case escape hatch that let a negative copy survive when MSG_SPLICE_PAGES was present.

This is the kind of kernel fix defenders like to see because it is narrow, legible, and easy to connect back to the primitive described in the disclosure. It is not a broad cleanup patch that leaves the exploitability question fuzzy.

Why this matters for package and CI incidents

CVE-2026-53362 is a local bug, but that does not make it low priority for AppSec teams. The important question is what happens after an attacker already has code execution on Linux:

malicious npm package on a developer workstation
poisoned PyPI dependency on a self-hosted runner
compromised build step inside a rootless container
ordinary app bug yielding a low-privilege shell

Any of those first-stage events can leave the attacker in exactly the position this bug needs: unprivileged code execution on a Linux host that still shares a vulnerable kernel with higher-value processes or containers.

That is why this belongs next to articles such as Dirty Frag, Januscape, and SCTPhantom. The package compromise is often stage one. The kernel is what decides whether stage two reaches root.

Scoping and detection

Start with the running kernel, not only what package management says is installed:

uname -r

Then check whether the namespace preconditions are plausible on the host:

sysctl user.max_user_namespaces 2>/dev/null
sysctl kernel.unprivileged_userns_clone 2>/dev/null
rg 'CONFIG_IPV6=|CONFIG_USER_NS=' "/boot/config-$(uname -r)"

For vendor kernels, changelog evidence is more reliable than branch names alone:

rpm -q --changelog kernel | rg 'CVE-2026-53362|ipv6: account for fraggap'

apt changelog "linux-image-$(uname -r)" 2>/dev/null | \
  rg 'CVE-2026-53362|ipv6: account for fraggap'

Runtime telemetry is harder, but the public exploit shape gives defenders a few signals worth watching:

  • unexpected namespace creation by low-trust processes
  • splice() or vmsplice() activity feeding UDPv6 sockets
  • repeated sendmsg() activity on corked UDPv6 sockets from unusual local processes
  • post-compromise investigations on container hosts where the attacker appeared to move from a contained process to host-level effects

CISA’s KEV entry requires forensic triage. Treat that as a hint that patching alone is not the whole response if you know hostile code already ran on the box.

Mitigation

The right fix is to install a vendor kernel that carries the upstream patch and then boot into it. For this issue, “the package is installed” is not enough if the old kernel is still the one running.

Where patching has to wait, Red Hat recommends reducing exposure by disabling unprivileged user namespaces:

sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-disable-userns.conf

That is a temporary reduction in attack surface, not a substitute for the fixed kernel. It can also break rootless Podman and other sandboxing workflows, so teams need to test the tradeoff before applying it broadly.

The operational lesson is straightforward. If you run Linux developer systems, CI runners, or container hosts, and you model package compromise or local app footholds as realistic, then a fresh KEV-listed kernel LPE is part of your application-security problem. CVE-2026-53362 is the latest reminder that “attacker only got local code execution” is rarely the end of the story on an unpatched Linux host.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References