ZDI-CAN-33367: Patched kernels released

Key points

AlmaLinux has released patched kernels for AlmaLinux 8, 9 and 10 that fix ZDI-CAN-33367, a local privilege escalation in the kernel's networking code. First published to the testing repository on 2026-10-23, the fix has been part of the regular kernel updates in the production repositories since 2026-10-28, so the testing repository is no longer needed. A working proof-of-concept was published together with the report.

The vulnerability

• Trend Micro's Zero Day Initiative reported it to the kernel security team and public kernel mailing lists on 2026-10-21. ZDI rates it CVSS 7.8 (High).
• An unprivileged local user can alter files they can read but not write, such as root-owned files, by corrupting the kernel's page cache copy of them.
• It is the same class of bug as Dirty Frag and Fragnesia, reached through a different code path.
• Cause: skb_zerocopy() is used by NFQUEUE and Open vSwitch to move packet data between buffers. It kept file pages attached via splice(2) but dropped the SKBFL_SHARED_FRAG marker.
• Without that marker, IPsec ESP decrypts in place over the cached file pages. Fragnesia was the same mistake in skb_try_coalesce().
• Upstream fix: "[PATCH v2 net] net: skbuff: propagate shared-frag marker in skb_zerocopy()". Zizhen Liu wrote it, Eric Dumazet reviewed it, and it was posted to netdev on 2026-10-22.
• No CVE has been assigned yet. The post will be updated once one is.

Who is affected

• All supported releases (AlmaLinux 8, 9 and 10) contain the vulnerable code. The modules the exploit needs ship in the standard kernel package.
• The proof-of-concept runs as an ordinary user with no capabilities. It relies on unprivileged user namespaces, which AlmaLinux allows by default.
• The highest risk is on multi-tenant hosts, container build farms, CI runners, and any system where untrusted users can get a shell.
• The file on disk is not changed. Every process reading the file sees the altered bytes until the pages are evicted or the system reboots.
• Dirty Frag and Fragnesia used this same technique to gain root, by tampering with files such as /usr/bin/su.

Shipping ahead of RHEL

• No fixed RHEL kernel existed when the post was written.
• The AlmaLinux core team backported the netdev fix to every supported branch, adapting it for the older socket-buffer code in AlmaLinux 8.
• The technical steering committee, ALESCo, approved shipping ahead of a CentOS Stream / RHEL update.
• The kernels went to the testing repository on 2026-10-23 for community verification and reached the production repositories on 2026-10-28.

Patched versions

• AlmaLinux 8: kernel-4.18.0-553.178.1.el8_10
• AlmaLinux 9: kernel-5.14.0-687.60.1.el9_8
• AlmaLinux 10: kernel-6.12.0-211.69.1.el10_2
• AlmaLinux Kitten 10 gets no separate build. The fix will arrive with its next regular kernel update.
• Install the listed version for your release or a later one.
• The kernels first released to testing (kernel-4.18.0-553.177.2.el8_10, kernel-5.14.0-687.59.2.el9_8 and kernel-6.12.0-211.68.2.el10_2) also contain the fix; the production kernels replace them.

How to update

• Update from the regular repositories and reboot:

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

• After rebooting, confirm with uname -r that the running kernel is the listed version or later.
• Most mirrors sync every few hours. If the update does not show up yet, try again later.
• If you enabled the testing repository to help test the kernels, disable it again:

sudo dnf config-manager --disable almalinux-testing

Temporary mitigation

• The exploit writes through IPsec ESP decryption, so blocking the esp4 and esp6 modules stops it.
• If the Dirty Frag or Fragnesia mitigation is still in place, the system is already covered.
• Neither module is normally loaded on systems without IPsec. The command below works unchanged on all supported releases. It writes a modprobe config that prevents loading and makes a best-effort attempt to unload the modules:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/zdi-can-33367.conf; rmmod esp4 esp6 2>/dev/null; true"

• To undo it, delete /etc/modprobe.d/zdi-can-33367.conf.
• To verify, run the command below. Empty output means the mitigation is active.

lsmod | grep -E '^esp(4|6)'

• If a module still appears, it is in use (for example by an active IPsec connection). The system stays exposed until you reboot into the patched kernel.
• Do not use this mitigation on systems that rely on IPsec, because those workloads will break. The real fix is the patched kernel plus a reboot.

If you suspect tampering

• Drop the page cache so the next read comes from disk:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

• Pages still mapped by running processes are not evicted this way. Rebooting into the patched kernel is the most reliable way to clear any tampering.

Summary by DistroNews, based on the original post.