Security News Public Exploits Released for Four Linux Kernel Flaws That Enable Local Root

[Captain Awesome]

Content source

https://thehackernews.com/2026/09/public-exploits-released-for-four-linux.html?m=1

A security researcher has released working exploit code for four Linux kernel flaws that each let a local user gain root, the highest level of access on a machine.

Kernel maintainers have fixed all four over the past few weeks, so a system running an up-to-date kernel is not affected. But the exploit code is now public, and any machine still running an older kernel should be updated.

The flaws are called DirtyAH6, TUNderflow, PPPoEject, and DiagSpill. Researcher Asim Manizada found them and reported them to the Linux kernel security team in mid-July.

He published a technical write-up with working exploits on September 18, after a coordinated hold with Linux distributions so the fixes could be released first.

So far, there are no reports of the four being used in real-world attacks. The exploits are Manizada's own, are tuned to specific kernel builds, and can crash a machine, so they are meant for isolated test systems.

What To Do

Update to a kernel that carries all four fixes. The first stable kernel releases with the complete set are:

5.10.270
5.15.221
6.1.188
6.6.157
6.12.109
6.18.50
7.2.4
These are the version numbers from the main Linux kernel project. Most people run a kernel from a distribution instead, such as Debian, Ubuntu, Red Hat, or SUSE, which uses its own version numbers and adds these fixes on its own schedule. Check your distribution's security advisory to confirm it has shipped an update that includes all four, rather than matching the numbers above.

 

[Bot AI]

What To Do

Hi, the practical advice is sound: install your distribution’s latest supported kernel update and reboot into it. Don’t compare a Debian, Ubuntu, RHEL or SUSE kernel version directly with the listed upstream numbers; distributions commonly backport security fixes without adopting the same version string.

What users should check​

1. Apply normal security updates through the distribution’s package manager.
2. Reboot if a new kernel was installed. Merely installing it leaves the currently running, older kernel in memory.
3. Check the active kernel afterward with `uname -r`.
4. If confirmation matters for a server or managed fleet, consult that distribution’s advisory or package changelog for the four fixes. The supplied information does not confirm which distribution-specific builds contain them.

Avoid installing a mainline kernel manually just to reach one of the quoted upstream versions unless that is already how the system is maintained. Using the vendor-supported kernel generally preserves its backports, packaging and support path.

Risk in context​

These are local privilege-escalation flaws. An attacker would normally need some way to execute code as a local, non-root user first—through an existing account, a compromised service, malicious workload or another foothold. They are not described here as remotely exploitable by themselves.

Public exploit code raises the urgency for multi-user systems, shared hosting, developer machines, container hosts and servers where an untrusted process might run. It does not mean every unpatched Linux desktop has already been compromised. Likewise, a container is not automatically a complete boundary against kernel flaws because containers share the host kernel.

There is no good reason to run the proof-of-concept on a production machine: success could grant root, while failure could simply crash the host. Patch verification is safer—and rather less theatrical.