Asim Manizada publishes working local-root exploits for four Linux kernel bugs

A kernel privilege escalation usually waits for the next maintenance cycle because the attacker has to be on the box already. The dev.to post that collected these four bugs argues that this discount fails for self-hosted infrastructure. In its account, a compromised web app, a rogue package or an LXC container with a shared kernel each becomes full node ownership once a local root bug is available ^[13]. I think that is right, for one specific reason. Proxmox LXC containers run on the host kernel ^[8]. The same kernel these bugs attack is the one enforcing the boundary between container and host. Working proof-of-concept code is public for all four ^[4], so the second step of that chain needs no exploit development.

The post does not describe the bugs' internals or say whether any of them depends on a non-default config option. For per-CVE detail it points to the oss-security thread and Manizada's write-up ^[14]. Until that detail says otherwise, I would treat every node on an unfixed branch as exposed.

The 7.0 series has a timing problem. It reached end of life on 27 June 2026 ^[7]. Manizada reported the bugs in mid-July ^[5]. The branch closed a few weeks before the report, so no upstream 7.0 stable release was ever going to carry the fixes ^[18]. A 7.0 kernel has them only if its vendor backported them ^[7]. The only 7.x release on the upstream list is 7.2.4 ^[6].

Checking coverage takes more than reading a version string. Vendors backport fixes ^[7], so a distribution's version number does not map cleanly onto the upstream list. The post checked a status snapshot on 29 September against the Debian and Ubuntu trackers and the Proxmox kernel changelog ^[1]. In that snapshot, Debian 13 trixie fixed all four in linux 6.12.111-1, shipped as DSA-6528-1 ^[10]. That is two releases past the upstream 6.12.109 floor ^[19]. Debian 12 bookworm's 6.1.187-1 fixed DirtyAH6, PPPoEject and DiagSpill, with TUNderflow the exception ^[11]. That package sits one release below 6.1.188, the first upstream 6.1 release the post lists with all four fixes ^[20]. The post's advice is to cross-reference the running version against the distribution's security advisory ^[16].

Installing the package changes nothing on a running host. The old kernel stays in memory until a reboot ^[9]. The kernel in memory does not consult apt.

The post's sequence for Debian-family hosts, including Proxmox and Raspberry Pi OS, runs like this:

1. Record `uname -r` on every node ^[16]. 2. Run `sudo apt update && sudo apt full-upgrade -y`, and on Proxmox confirm the packages with `pveversion -v` ^[15]. 3. On Raspberry Pi OS Bookworm or newer, check `apt-cache policy linux-image-rpi-v8` (or `linux-image-rpi-2712`, depending on the board). Installed and Candidate should match ^[12]. 4. On Proxmox, shut down or migrate guests with `qm shutdown` and `pct shutdown` before rebooting the host ^[17]. 5. Reboot, run `uname -r` again and compare it with the distribution's advisory ^[16].

Step 3 matters because the package name changed. Bullseye and earlier shipped the kernel as `raspberrypi-kernel`, and Bookworm moved to Debian-style `linux-image-rpi-*` packages ^[12]. Querying the old name on a current install checks the wrong package ^[12].