🕳️ IPv6 Fraggap Overflow Advisory

IPv6 fraggap overflow: local privilege escalation through a heap overflow in the Linux IPv6 UDP send path
CVE-2026-53362     CVSS 7.8 High (kernel CNA)     published July 4, 2026     Ubuntu: High     Red Hat: Important     On CISA's Known Exploited list since 2026-08-27

An ordinary local user, with no special privileges, can send specially arranged UDP packets over IPv6 and make the kernel write a few bytes past the end of a memory buffer. That is enough to corrupt kernel memory, and public write-ups describe it being turned into root access. One researcher write-up nicknames it "Frag Gap".
Versions and advisories below were checked on 2026-10-01 against the Ubuntu CVE tracker, Red Hat's CVE data and bulletin, and NVD (read through a summarising tool, so re-check a number against the vendor page before you rely on it). A kernel NEWER than the one listed also contains the fix. Ubuntu's fixes were still moving on that date: the "Live vendor status" card at the top of this page is newer than the text below.
Defensive notes only: no exploit code here. Only run the mitigation on machines you own or administer.
IMPORTANT: CISA added this CVE to its Known Exploited Vulnerabilities catalog on 2026-08-27 (due date 2026-08-30). Treat it as "being used in the wild": patch, do not just mitigate.

When a program sends UDP data over IPv6 in several pieces (the socket option MSG_MORE keeps one packet open for more data), the kernel builds the packets in a function called __ip6_append_data(). In one code path it works out how big the buffer for the next fragment must be, and it forgets to include "fraggap": a few bytes carried over from the previous fragment. The buffer comes out too small by exactly that many bytes, the kernel then copies the carried-over bytes into it anyway, and the copy runs past the end of the buffer into the kernel's own bookkeeping data for the packet (skb_shared_info).
It needs an unprivileged user to be able to open a UDPv6 socket and send with MSG_MORE together with MSG_SPLICE_PAGES (a zero-copy feature). No special permissions are needed. It is a LOCAL bug: someone must already be able to run code on the machine. It is not something a stranger on the network can trigger by sending packets to you.
The mistake was introduced in 2022 (commit 773ba4fe9104, "ipv6: avoid partial copy for zc"). For a while the bad arithmetic was harmless, because the kernel rejected the case with an error. A later change in 2023 (commit ce650a166335) allowed it to go through, and that made the memory corruption reachable. My reading of that history is that it explains why older enterprise kernels are not affected: Ubuntu 20.04 and the 22.04 base kernel (5.x) and RHEL 6, 7, 8 and 9 (3.10, 4.18, 5.14) are listed as not affected.
NVD lists upstream kernels from 6.0 up to the fixed versions as in range. The upstream fix (mainline commit 736b380e28d0, "ipv6: account for fraggap on the paged allocation path") adds fraggap to the buffer size and removes the special case that let the bad value through.
Fixed upstream in: 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3 (and later). Distribution kernels have their own numbers, see the tables below.

Ubuntu:          24.04 (kernel 6.8 and its 6.17 HWE), and 22.04 only if it runs the 6.8 HWE kernel. Fixed in 26.04 and in the 24.04 7.0 HWE kernel. NOT affected: 20.04, the standard 22.04 (5.15) kernel, 18.04, 16.04, 14.04. 25.10 is end-of-life: upgrade.
Red Hat family:  RHEL 10 only (and products on its kernel). RHEL 6, 7, 8 and 9 (including kernel-rt) are NOT affected. OpenShift 4 is not affected, because it runs on RHEL 9.
Others:          Debian, SUSE, Amazon Linux and rebuilds published their own advisories. Follow them.
Needs:           a kernel with IPv6 compiled in (this is normal), and a local user able to run code. IPv6 does not need to be actually used on your network: the code is in the kernel anyway.
Most at risk:    shared servers, container hosts, Kubernetes nodes, CI runners, jump boxes and anything where untrusted people or programs run code.

IPv6 is built into the standard Ubuntu and RHEL kernels (it is not a loadable module you can simply switch off with modprobe). That is why the usual "block the module" trick does not apply here.
Check:
grep -E 'CONFIG_IPV6=' /boot/config-$(uname -r)               # =y means built in
cat /proc/sys/net/ipv6/conf/all/disable_ipv6                   # 0 means IPv6 is enabled on this machine
lsmod | grep -w ipv6                                           # normally prints nothing (built in)

uname -r                                                       # the kernel you are running RIGHT NOW (compare with the tables below)
sysctl user.max_user_namespaces                                # how many user namespaces are allowed (0 = disabled, see the Red Hat mitigation)
cat /proc/sys/kernel/apparmor_restrict_unprivileged_userns 2>/dev/null     # Ubuntu 24.04: 1 means AppArmor limits unprivileged user namespaces
Be careful with assumptions about namespaces: Red Hat's own mitigation works by limiting user namespaces, but a third-party technical write-up says the bug is reachable without special namespace setup. Do not rely on namespace settings as protection. Patch.

The situation differs by vendor:
Red Hat (bulletin RHSB-2026-009): disable unprivileged user namespaces:
   sudo sysctl -w user.max_user_namespaces=0                                           # takes effect immediately, lost at reboot
   echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-disable-userns.conf   # makes it permanent
   Undo later: sudo rm /etc/sysctl.d/99-disable-userns.conf  then  sudo sysctl -w user.max_user_namespaces=65534
   Red Hat's own warning: this breaks anything that needs unprivileged user namespaces, including rootless Podman containers and some application sandboxes. If you use those, patch instead.
Ubuntu: Ubuntu publishes no workaround for this CVE. The same sysctl works on Ubuntu too, but it is Red Hat's advice, not Ubuntu's, and the caveat above applies even more: web browsers, Flatpak and Snap sandboxes and rootless containers commonly rely on user namespaces. On Ubuntu 24.04, AppArmor normally already restricts unprivileged user namespaces (check the apparmor_restrict_unprivileged_userns line above).
The honest position: none of the manual measures is a reliable shield for this bug. The independent write-up says it cannot be reliably prevented by restricting the splice() system call alone, and says it does not need special namespaces. Treat the sysctl as a small extra hurdle, not a fix.
Blunt option (my addition, not published by any vendor for this CVE, and untested against this bug): turn the IPv6 stack off completely with the boot argument ipv6.disable=1, so IPv6 sockets cannot be created at all. It breaks IPv6 networking and software that expects IPv6 (even loopback ::1), so only consider it on a machine that does not use IPv6 at all, and test first.
Containers: the host kernel is what matters, so patching the host fixes every container on it.

Ubuntu:
   sudo apt update && sudo apt upgrade
   sudo reboot
Red Hat / RHEL 10:
   sudo dnf upgrade --refresh 'kernel*'
   sudo reboot
A kernel update does nothing until you boot into it. Run uname -r afterwards and compare with the tables below.
Ubuntu 24.04 on the standard 6.8 kernel: when this was checked (2026-10-01) the fix was PREPARED (6.8.0-147.147) but NOT yet released as a normal update. Until it arrives you can move to the 7.0 HWE kernel (already fixed):
   apt-cache policy linux-generic-hwe-24.04            # which HWE kernel does this meta package give you right now?
   apt search '^linux-image-7.0'                       # is a 7.0 kernel image available to install?
   Install the 7.0 HWE kernel package your Ubuntu documentation names for 24.04, reboot, and confirm with uname -r that it starts with 7.0.
Red Hat also released a live kernel patch (kpatch) for RHEL 10 (RHSA-2026:43826, July 22 2026), which applies the fix without a reboot. A reboot into the new kernel is still the cleanest state.

Patched kernels: Ubuntu (as of 2026-10-01; anything newer is also fixed)
Release              Kernel line                 Status / fixed in
26.04 LTS Resolute   linux (7.0)                 fixed: 7.0.0-31.31
24.04 LTS Noble      linux-hwe-7.0               fixed: 7.0.0-31.31~24.04.1
24.04 LTS Noble      linux (6.8 GA)              fix prepared, NOT yet released: 6.8.0-147.147
24.04 LTS Noble      linux-hwe-6.17              vulnerable, no fix yet (move to the 7.0 HWE or the 6.8 GA fix when it ships)
22.04 LTS Jammy      linux-hwe-6.8               fix prepared, NOT yet released: 6.8.0-147.147~22.04.1
22.04 LTS Jammy      linux (5.15)                not affected
20.04, 18.04, 16.04, 14.04                       not affected
25.10 Questing                                   end-of-life, ignored: upgrade
Noble cloud and special kernels: fixed in the 7.0 flavours (linux-aws-7.0 7.0.0-1012.12~24.04.1, linux-azure-7.0 7.0.0-1014.14~24.04.1, linux-gcp-7.0 and linux-oracle-7.0 7.0.0-1011.11~24.04.1, linux-nvidia-7.0 7.0.0-1018.18~24.04.1). On the 6.8 line they were "fix prepared, not released": linux-aws 6.8.0-1067.70, linux-azure and linux-gcp 6.8.0-1071.79, linux-gke 6.8.0-1066.74, linux-oracle 6.8.0-1064.67, linux-lowlatency 6.8.0-147.147.1.
26.04 cloud kernels (all fixed): linux-aws 7.0.0-1012.12, linux-azure 7.0.0-1014.14, linux-gcp 7.0.0-1011.11, linux-gke 7.0.0-1006.7, linux-oracle 7.0.0-1011.11, linux-raspi 7.0.0-1019.19.
Look up any other flavour on https://ubuntu.com/security/CVE-2026-53362. "Pending" in Ubuntu's tracker means the fix is built and in testing but not in the normal update channel yet.

Patched kernels: Red Hat Enterprise Linux (kernel package; "or newer" applies)
RHEL 10 (10.2)        6.12.0-211.30.1.el10_2      (RHSA-2026:34911, July 2 2026)
RHEL 10.0 EUS         6.12.0-55.86.1.el10_0       (RHSA-2026:35840, July 6 2026)
NVIDIA for RHEL 10    6.12.0-231.14.el10nv        (RHSA-2026:34927, July 2 2026)
RHEL 10 kpatch        kpatch-patch                (RHSA-2026:43826, July 22 2026)
RHEL 6, 7, 8 and 9 (kernel and kernel-rt): not affected.
Rebuilds (AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux) use their own package numbers: follow their advisories, not this table.
Red Hat's fixes for this CVE are from July 2026, so a RHEL 10 machine updated since then should already have it.

Is my kernel patched?
Ubuntu:
   uname -r                                                         # compare with the Ubuntu table above
   apt changelog linux-image-$(uname -r) | grep CVE-2026-53362      # the changelog should mention the CVE
   pro fix CVE-2026-53362 --dry-run                                 # Ubuntu Pro client: says whether this machine is fixed
Red Hat / RHEL 10:
   uname -r                                                         # compare with the RHEL table above
   rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-53362      # the changelog should mention the CVE
   sudo dnf updateinfo list --cve CVE-2026-53362                    # which advisory fixes it and whether it is installed
   sudo needs-restarting -r                                         # says whether a reboot is still needed
Careful: rpm -q kernel and dpkg -l 'linux-image*' list INSTALLED kernels, including old ones you are not running. Only uname -r tells you what is actually running.

This bug is local, so the question is whether someone untrusted could already run code on the host. Worth checking on such machines:
   cat /proc/sys/kernel/core_pattern                  # normally starts with a pipe to your distro's crash handler (Ubuntu: |/usr/share/apport/apport ..., RHEL: |/usr/lib/systemd/systemd-coredump ...)
One third-party write-up describes overwriting this setting as the final step of an exploit, so an unexpected value (a path to a script or binary you do not recognise) is a red flag. It is a single indicator, not proof either way.
Also review who logged in and what ran: last, journalctl -b, your EDR or audit logs, and unexpected new users, SSH keys or cron entries. If you find signs of compromise, rebuild the machine from a known-good image rather than cleaning it.

I updated but uname -r shows the old kernel: you have not rebooted yet. The patch only counts once the new kernel is running.
Ubuntu 24.04 shows no fixed 6.8 kernel: that was the state on the date above (fix prepared, not released). Run apt update again in a day or two, or use the 7.0 HWE kernel.
My 22.04 machine says "not affected": the standard 5.15 kernel is not affected, but a 22.04 machine running the 6.8 HWE kernel is. Check uname -r: a 6.8 kernel means HWE.
Rootless containers or a browser sandbox broke after I set user.max_user_namespaces=0: that is the side effect Red Hat warns about. Undo it and patch instead.
IPv6 is disabled on my machine, am I safe?: not necessarily. Turning IPv6 off with the usual sysctls removes addresses, but the code is still in the kernel. Patch.
A cloud image shows a kernel name like 6.8.0-1067-aws: cloud kernels have their own fixed numbers. Do not compare them with the generic 6.8.0-147 line.

Patch and reboot beats every workaround. Treat the sysctl as a bandage for hosts you cannot reboot yet, then remove it.
Prioritise by who can run code: container hosts, Kubernetes nodes, CI runners, shared servers and jump boxes come first.
This is the latest in a run of kernel local privilege escalations covered on this site (Dirty Frag, Copy Fail and the others). "Local only" does not mean "low priority" when anything on the machine (a web app bug, a stolen SSH key, a CI job) can give an attacker a local foothold.
Your 22.04 and 24.04 machines can be in different situations for the same CVE (kernel line matters, not just release): always compare uname -r with the table.
Put the date and reason in a comment next to any sysctl you change. "Why can nobody run rootless Podman here?" is a bad mystery at 2 a.m.
The bug was a missing "+ fraggap". One missing addition, one overwritten buffer. The compiler had no complaints.

Ubuntu CVE tracker:                 https://ubuntu.com/security/CVE-2026-53362
Red Hat CVE page:                   https://access.redhat.com/security/cve/cve-2026-53362
Red Hat security bulletin:          https://access.redhat.com/security/vulnerabilities/RHSB-2026-009
Red Hat CVE data feed:              https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-53362.json
NVD entry:                          https://nvd.nist.gov/vuln/detail/CVE-2026-53362
CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-53362
Upstream fix:                       https://git.kernel.org/stable/c/736b380e28d0480c7bc3e022f1950f31fe53a7c5
Third-party technical write-up ("Frag Gap"): https://blog.qwerty.or.kr/en/posts/cdf3008a-c1a4-4eca-a373-aa3a2bcf1489/