ZDI-CAN-33367: Patched kernels available in testing

A new Linux kernel vulnerability, tracked by Trend Micro’s Zero Day Initiative (ZDI) as ZDI-CAN-33367, was reported to the kernel security team and public kernel mailing lists on 2026-10-21. It lets an unprivileged local user change the contents of files they can read but not write, such as files owned by root, by corrupting the kernel’s in-memory copy of those files (the page cache). ZDI classifies it as a local privilege escalation with a CVSS score of 7.8 (High). AlmaLinux 8, 9, and 10 are affected. Patched kernels are available in the testing repository today, and we would like your help verifying them before we release them to production.

If this sounds familiar, it should. ZDI-CAN-33367 is the same kind of bug as Dirty Frag and Fragnesia, reached through a different path in the kernel’s networking code. The report was posted to public mailing lists together with the source code of a working proof-of-concept.

If you run AlmaLinux on a multi-tenant host, container build farm, CI runner, or any system where untrusted users can get a shell, this one matters.

More information about the vulnerability:

• ZDI report on the kernel mailing list: https://lore.kernel.org/lkml/BYAPR01MB3830CECF5D0871064C59BA0280662@BYAPR01MB3830.prod.exchangelabs.com/
• Upstream fix on the netdev mailing list: https://lore.kernel.org/all/20261022104217.1852191-1-pointerliu@126.com/
• Patch subject: [PATCH v2 net] net: skbuff: propagate shared-frag marker in skb_zerocopy()

No CVE has been assigned yet. We will update this post when one is.

Summary

When a network packet carries pages the kernel doesn’t own, such as file pages attached with splice(2), the kernel marks it with SKBFL_SHARED_FRAG so that IPsec ESP knows not to decrypt over them in place. The bug is in skb_zerocopy(), which NFQUEUE and Open vSwitch use to move packet data between buffers: it kept the file pages but dropped the marker. ESP then decrypts in place, writing directly over the cached pages of a file the attacker can only read. Fragnesia was the same mistake in a different helper, skb_try_coalesce().

The fix, written by Zizhen Liu and reviewed by Eric Dumazet, makes skb_zerocopy() keep the marker. It was posted to the netdev mailing list on 2026-10-22.

Impact

Every supported AlmaLinux release (8, 9, and 10) ships the vulnerable code, and the modules the proof-of-concept relies on are part of the standard kernel package. The proof-of-concept runs as an ordinary user with no capabilities. It uses an unprivileged user namespace to set up its own network configuration, which AlmaLinux allows by default.

The change only exists in memory. The file on disk is not modified, but every process that reads the file sees the attacker’s bytes until the cached pages are evicted or the system is rebooted. That is the same primitive Dirty Frag and Fragnesia used to gain root, by tampering with files such as /usr/bin/su.

Patching ahead of our upstream

Security is a top priority at AlmaLinux. This flaw lets an unprivileged user tamper with read-only files through the same code area as Dirty Frag and Fragnesia, and a working proof-of-concept is already public, so we did not want to wait. At the time of writing, no fixed RHEL kernel is available. Our core team has backported the fix posted to netdev to every supported AlmaLinux branch, adapting it for the older socket-buffer code in AlmaLinux 8. The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.

These kernels are available in the testing repository today. After the community has helped verify them, we will release them to the production repositories. This post will be updated when that happens.

Patched kernel versions

• AlmaLinux 8: kernel-4.18.0-553.177.2.el8_10
• AlmaLinux 9: kernel-5.14.0-687.59.2.el9_8
• AlmaLinux 10: kernel-6.12.0-211.68.2.el10_2
• AlmaLinux Kitten 10: the fix will ride along in the next regular kernel update, so no separate build is being made

Install the version listed for your release, or higher.

Help us test

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

Confirm with uname -r or rpm -q kernel against the versions above.

If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have rebooted:

sudo dnf config-manager --disable almalinux-testing

If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org.

Temporary mitigation if you cannot reboot yet

The proof-of-concept writes into the page cache through IPsec ESP decryption, so blocking the esp4 and esp6 modules blocks it. If you applied the mitigation from the Dirty Frag or Fragnesia posts and still have it in place, you are already covered.

If you have not, you can block the modules now. Neither is loaded on a typical system that does not use IPsec, so on most systems this is safe to apply immediately:

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"

This writes a modprobe config that prevents the two modules from loading, and unloads them if they are already loaded (the rmmod is best-effort and silent if a module isn’t loaded). The command is safe to run unchanged on all supported releases. To revert, remove /etc/modprobe.d/zdi-can-33367.conf.

Check that neither module is still loaded:

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

No output means the mitigation is active. If either module is listed, it is in use (for example by an active IPsec connection) and could not be unloaded, so the system stays exposed until you reboot into the patched kernel.

If you suspect the system may have been targeted before you applied the mitigation, drop the page cache so that tampered pages are evicted and the next read comes fresh from disk:

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

Pages that a running process still has mapped are not evicted this way, so rebooting into the patched kernel is the most reliable way to clear any tampering.

Do not rely on this if you actually use IPsec. Those workloads will break. The proper fix is to install the patched kernel and reboot.

Thanks

Thanks to Trend Micro’s Zero Day Initiative for reporting this vulnerability, to Zizhen Liu for writing the upstream fix, and to Eric Dumazet for reviewing it.

Thanks to the AlmaLinux core team for turning around patched builds for every supported release, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you in advance to everyone in the community who helps us test these kernels. That’s the part that gets them safely into production.

Stay informed

Remaining aware of these vulnerabilities and acting quickly can keep your systems and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed. We will update this post when the patched kernels move from testing to production.

Changelog

• 2026-10-23: Initial post published. Patched kernels available in almalinux-testing for AlmaLinux 8, 9, and 10.