Linux Kernel Privilege Escalation Flaw CVE-2026-46215: PoC and Full Write-Up Public
Do Son 
- CVE: CVE-2026-46215
- CVSS: 7.8 (High · CVSSv3)
- Product: Linux
- Affected: 53096728b8910c6916ecc6c46a5abc5c678b58d9, 6.18
- Impact: drm: Set old handle to NULL before prime swap in change_handle
- Status: No confirmed exploitation yet
- Patched in: 672464dd53231509c9c771110798c56d4660e19e, 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025, 5e28b7b94408897e41c63477aabc9e1db439bc8c, 6.18.32 (+2 more)
- EPSS: 0.1% (30-day)
- Action: Update to 672464dd53231509c9c771110798c56d4660e19e, 61bd96d3e5472c253f9c1ab77608f0c8aaa9d025, 5e28b7b94408897e41c63477aabc9e1db439bc8c, 6.18.32 (+2 more) now
TL;DR
A researcher has published a full technical write-up and proof-of-concept exploit for a Linux kernel privilege escalation flaw. Tracked as CVE-2026-46215 (CVSS 7.8), it is a use-after-free in the DRM GEM subsystem. Any logged-in user on a stock desktop can reach it and gain root. No in-the-wild exploitation has been confirmed.
Why It Matters
This Linux kernel privilege escalation bug needs no special access. DRM render nodes exist so unprivileged clients can submit GPU work. On major desktop distributions, systemd-logind grants the active session read/write access to that node by default.
As a result, an ordinary local user can trigger the flaw. There is no capability, setuid helper, or container escape required. That makes it one of the strongest local threat models a bug can carry. Shared workstations and multi-user Linux hosts face the clearest exposure. A single low-privilege account becomes a path to full control.
How the Attack Works
A Race in change_handle
The flaw lives in the newer DRM_IOCTL_GEM_CHANGE_HANDLE call. It moves a GEM object from one handle to another. However, it never adjusts the object’s handle_count.
For a brief window, the object has two handle entries while the count still reads 1. A concurrent GEM_CLOSE on the old handle drives that count to 0. The kernel then frees the object while the new handle still points at it. That dangling handle is the use-after-free. The freed object lands in the kmalloc-512 cache, which the exploit reuses. On a two-core VM, the race wins within about 100 tries.
From Free to Root
According to the researcher’s detailed technical write-up, the exploit reclaims the freed slot with a sprayed pipe_buffer array. A driver info ioctl then leaks a kernel pointer, which defeats KASLR. Next, the chain sets a merge flag to bypass the earlier DirtyPipe fix. Finally, it overwrites read-only /etc/passwd through the page cache. The result is passwordless root about 99% of the time.
Exploitation Status
No attacks in the wild have been reported. Even so, a working proof-of-concept exploit sits on GitHub. Two researchers found the bug independently. Puttimet Thammasaeng reported it first and holds the CVE credit. The second researcher published the analysis and exploit chain covered here. This overlap shows how reachable the flaw really is.
Affected Versions
The vulnerable ioctl arrived in kernel v6.18-rc1 for AMD’s CRIU work. So the bug affects the 6.18 series through early 7.x builds. Systems without the change_handle ioctl are not affected. Distributions that ship kernels older than 6.18 avoid this specific bug. Still, admins should confirm their exact build before assuming safety.
Patch and Mitigation Steps
Update to a fixed kernel without delay. Patched releases are 6.18.32, 7.0.9, and 7.1-rc3 and later. The fix stops the new handle from ever pointing at a live object during the race. Where patching must wait, admins can restrict render node access. Given a public exploit, this Linux kernel privilege escalation flaw deserves urgent attention on every affected host.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
