ZDI-CAN-33367: reboot into the AlmaLinux kernels that close the page cache
On 21 October 2026 a local Linux bug was reported to the kernel list under ZDI-CAN-33367. AlmaLinux had production kernels for it by 28 October. The fix is a reboot, not a setting.
Trend Micro's Zero Day Initiative reported ZDI-CAN-33367 to the kernel security team and the public lists on 21 October 2026. AlmaLinux's note the same week calls it a local privilege escalation scored 7.8. An unprivileged local user can change the kernel's in-memory copy of a file they are allowed to read but not write, including files owned by root.
AlmaLinux did not publish a CVE number in that post. This article does not invent one. The identifier to track until a CVE is assigned is ZDI-CAN-33367.
What a poisoned page cache means
The page cache is the kernel's copy of file contents, shared by every reader. If a local user can alter that copy, the next reader — a service, a script, a setuid helper — can observe contents the file on disk does not have. AlmaLinux compares the shape to earlier cache bugs: the durable file can look clean while the running system saw something else.
The report is local. It is not a remote upload bug. On a machine where untrusted users can log in, or where a container shares the host kernel, local is enough.
Which files are in scope
Anything the attacker can read. Configuration that is world-readable, binaries that are world-executable, and keys that were stored with loose permissions all sit in the cache when something opens them. A write to the cache is not a write to the inode, so a checksum of the file on disk can still pass after the running view was wrong.
Shared build hosts and jump boxes are the boring places this lands. A single-user laptop with full-disk encryption is a smaller audience than a campus shell server.
The AlmaLinux kernels that include the fix
AlmaLinux pushed test kernels on 23 October 2026 and, on 28 October, said the fix was in the production repositories. The builds named in that post are kernel-4.18.0-553.178.1.el8_10 on AlmaLinux 8, kernel-5.14.0-687.60.1.el9_8 on AlmaLinux 9, and kernel-6.12.0-211.69.1.el10_2 on AlmaLinux 10.
Other enterprise rebuilds and upstream stable trees shipped their own builds. If you are not on AlmaLinux, match ZDI-CAN-33367 in your vendor's errata rather than installing an AlmaLinux RPM on a different distribution.
Upgrade and reboot
On AlmaLinux the project's own instruction is to refresh metadata, upgrade, and reboot. After the reboot, confirm the running kernel is at least the build above for your major version. A host that installed the package and stayed up is still on the old cache code.
Until that reboot, do not treat world-readable secrets on a shared host as private. Move them to a store that is not a mode 644 file, and keep untrusted users off the box. This note does not describe how the cache is altered.
AlmaLinux's note of 23 October 2026, updated 28 October, on ZDI-CAN-33367.
https://almalinux.org/blog/2026-10-23-zdi-can-33367/
Frequently asked questions
What is the CVE for ZDI-CAN-33367?
AlmaLinux's public note of 23 October 2026 does not give a CVE number. Track ZDI-CAN-33367 until your vendor's advisory prints one. Do not guess an identifier.
Is this remote?
No. It is a local user changing the kernel's cached view of a file they can read. Patch priority follows who can get a local shell, including through a container on that kernel.
Which AlmaLinux package is the fix?
AlmaLinux 8: kernel-4.18.0-553.178.1.el8_10 or later. AlmaLinux 9: kernel-5.14.0-687.60.1.el9_8 or later. AlmaLinux 10: kernel-6.12.0-211.69.1.el10_2 or later. Reboot.