A Kernel Bug Named 'Bad Epoll' Hands Any Local User Root — 99% of the Time. If You Run a Linux VPS, This Is Your Sunday.
A Kernel Bug Named 'Bad Epoll' Hands Any Local User Root, 99% of the Time. If You Run a Linux VPS, This Is Your Sunday.
CVE-2026-46242, nicknamed "Bad Epoll," is a use-after-free in the Linux kernel's epoll subsystem that lets an unprivileged local user escalate to root. The public proof-of-concept, written by Jaeyoung Chung, a PhD researcher at Seoul National University's CompSec Lab, widens the timing window enough to hit root roughly 99% of the time. It affects mainline Linux from 6.4 onward, plus the long-term-support branches distributions backport onto, and Android devices on 6.6-series kernels and newer, current Pixel hardware included. It's Sunday, July 5. This is a fifteen-minute job that's worth doing before you close the laptop.
What the bug actually is, in plain English
Epoll is the kernel machinery that lets a program watch a pile of file descriptors and get told when any of them is ready. Bad Epoll is a race between two parts of the kernel trying to clean up the same internal object at the same instant: one frees the memory while the other is still writing through a pointer to it. Set up two epoll descriptors to monitor each other, close both at nearly the same moment, and the kernel ends up reading and writing freed memory. From there an attacker corrupts kernel structures and climbs from an ordinary account to root.
The "local user" part is what people underweight. "You need local access first" sounds reassuring until you remember what a local user is on a modern box: any process that got a foothold. A compromised dependency running in your CI. A web app that got popped and now has a shell as www-data. A cheap shared host where "local" includes other tenants. Bad Epoll is the bug that turns any of those from "annoying, contained" into "root on the whole machine."
Why this one matters more for a solo operator
Big companies run this stuff in isolated, least-privilege, one-service-per-host setups where a local-to-root escalation is bad but bounded. You, probably, do not. The default solo-operator deployment is one VPS doing everything: the app, the database, the background jobs, the deploy user, maybe a second little side project you forgot about. There's no blast wall. Root on that box is root on your entire business: the database, the API keys in the environment, the SSH keys that reach your other boxes, the lot.
So the standard "meh, it's only local privilege escalation" dismissal is exactly backwards for how most of us actually deploy. The single-box economy that makes a one-person business cheap to run is the same thing that makes a local-to-root bug a full compromise.
The footnote that should make you think
Here's the detail I can't stop chewing on. In the same roughly 2,500-line stretch of kernel code, there were two closely related race conditions. Anthropic's Mythos model caught the first one (that's CVE-2026-43074) and genuinely helped. It then walked right past the second one sitting immediately next to it. That second one is Bad Epoll, and it took a human researcher to find.
I'm not telling you AI code auditing is useless; catching the adjacent bug is a real result. I'm telling you that "we ran it through the model and it came back clean" is not a threat model. The model found one of two nearly identical flaws in the same function and missed the worse one by inches. If you've quietly started trusting an AI reviewer as your security backstop (and a lot of solo operators have, because it's cheaper than a pentest), this is your reminder that it's a smoke detector, not a sprinkler system. Useful, not sufficient.
The 15-minute Sunday fix
Nothing exotic here. Patch the kernel and reboot.
Check what you're running:
uname -r
If that reports a 6.4 or newer mainline kernel, or your distro's backport of one, assume you're in scope until you've confirmed otherwise. Then update and reboot into the new kernel:
# Debian / Ubuntu sudo apt update && sudo apt upgrade -y sudo reboot # Fedora / RHEL family sudo dnf upgrade --refresh -y sudo reboot # Arch sudo pacman -Syu sudo reboot
Two things people skip. First, the fix only counts once you've rebooted into the patched kernel: apt upgrade installs it, but you keep running the old one until the reboot, so don't mark this done until uname -r shows the new version. Second, the mainline patch has been in the kernel since April 24, but the writeup only went public this month, and distributions ship backports on their own schedule. If apt upgrade doesn't offer a new kernel yet, your distro may not have shipped it. In that case, check your distro's security tracker for CVE-2026-46242, and in the meantime tighten who can get a local foothold at all.
Which is the boring, durable half of the fix and worth saying out loud: stop handing out shell accounts on the box that runs your business, run untrusted or internet-facing services as their own low-privilege users, and keep your Android phone on current security patches too, because it's affected by the same bug. A local-to-root exploit is only a problem if something hostile is already local. Give it fewer ways to get there and you've bought yourself margin even on the days your kernel is behind.
Patch, reboot, confirm the version, then go enjoy the rest of your Sunday.
Author
Lukas
@lukcombinator