Volver a los avisos de seguridad

Bad epoll (CVE-2026-46242) Local Root Exploit: Kernel Update for CloudLinux

CloudLinux is affected by CVE-2026-46242 (and 1 related CVEs). In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays. CVSS base score: 7.8.

Critical 7.8 CVSS
CloudLinux AlmaLinux 9 CloudLinux 7 CloudLinux 8 CloudLinux 9 Ubuntu 22.04

Comandos de corrección

EL8+ (AlmaLinux/CloudLinux/Rocky)

sudo dnf update

EL7 (CentOS/CloudLinux 7)

sudo yum update

Debian/Ubuntu

sudo apt update && sudo apt upgrade

Lo que esto significa bajo una licencia de SharedLicense

Your SharedLicense license itself is not affected — this is a vulnerability in CloudLinux software, not in licensing. Licenses continue to work during and after the update; there is no need to re-issue or re-activate anything. If you resell CloudLinux under your own brand, patch client servers too — unpatched installs put your reputation at risk, not your license.

Bad epoll (CVE-2026-46242) is a use-after-free bug in the Linux kernel’s epoll subsystem that lets an unprivileged local user escalate to root. It affects CloudLinux 9 and 10. Patched AlmaLinux kernels are in testing and a KernelCare livepatch is being prepared. Here’s how to update.
The post Bad epoll (CVE-2026-462…

Bad epoll (CVE-2026-46242) is a use-after-free bug in the Linux kernel’s epoll subsystem that lets an unprivileged local user escalate to root. It affects CloudLinux 9 and 10. Patched AlmaLinux kernels are in testing and a KernelCare livepatch is being prepared. Here’s how to update.
The post Bad epoll (CVE-2026-462…

Bad epoll (CVE-2026-46242) is a use-after-free bug in the Linux kernel’s epoll subsystem that lets an unprivileged local user escalate to root. It affects CloudLinux 9 and 10. Patched AlmaLinux kernels are in testing and a KernelCare livepatch is being prepared. Here’s how to update.
The post Bad epoll (CVE-2026-462…

Bad epoll (CVE-2026-46242) is a use-after-free bug in the Linux kernel’s epoll subsystem that lets an unprivileged local user escalate to root. It affects CloudLinux 9 and 10. Patched AlmaLinux kernels are in testing and a KernelCare livepatch is being prepared. Here’s how to update.
The post Bad epoll (CVE-2026-462…

In early July 2026, researcher Jaeyoung Chung (CompSec Lab, Seoul National University) published a proof-of-concept for Bad epoll, a use-after-free bug in the Linux kernel’s epoll subsystem. On CloudLinux 9 and 10 it lets an unprivileged local user escalate to root. On a shared host, that turns a single compromised website into root on the whole server.

The public exploit reports high reliability (99% on a 6.12 kernel), and it needs no special privileges or configuration to run.

Why this matters on a shared host

On CloudLinux 9 and 10, Bad epoll is the difference between one hacked website and a compromised server. A kernel local privilege escalation turns any code running on the server into root, and “local” here does not mean an insider or a customer you trust. It means any process on the machine, including the PHP-FPM worker behind a compromised WordPress plugin, an outdated CMS, or a site running on leaked credentials. The attacker is whoever hacked one of the sites you host.

On an unpatched host the chain is short, and none of it needs special access:

  1. A web-tier compromise. An attacker exploits a vulnerable WordPress plugin, an outdated CMS, or one of the everyday web-application flaws shared hosting sees constantly. They now run as the site’s PHP-FPM or Apache identity, or its CageFS account, in theory confined to that one site.
  2. Bad epoll. From that unprivileged process, the attacker uses the epoll use-after-free to become root. No prior root, no special capability, no admin action.
  3. Root on the host. They now run outside every CageFS boundary and every per-tenant limit. Every other tenant’s files, databases, credentials, and backups on that server are within reach, and recovery means rebuilding the whole server.

On a patched host, or one running a KernelCare livepatch, step 2 fails: a web-tier compromise stays a web-tier compromise, one site to clean up rather than a whole server to rebuild. That is what the kernel update buys you.

If a CloudLinux 9 or 10 server in your fleet has not taken the fix and is not on KernelCare, the gap between “a customer’s site got hacked” and “the whole server is owned” is this one kernel bug.

💡 Another kernel reboot cycle?

Bad epoll is the latest in a run of Linux kernel privilege-escalation issues that have each required a patch and a reboot on affected hosts. If emergency-patching and rebooting servers on this cadence is not sustainable for you, KernelCare is the alternative we recommend. It applies kernel security fixes to a running server automatically, with no reboot and no maintenance window. Once the Bad epoll livepatch reaches the main feed, servers running KernelCare receive it on the next update cycle. See Stream 3 below for current status.

Technical details of the bug

Bad epoll is a race condition in the kernel’s epoll event-notification subsystem. Two of epoll’s close paths run at the same time and collide: one path frees an object while the other is still writing into it, in ep_remove(). That is the use-after-free. It gives an 8-byte write into freed kernel memory, which the public exploit builds into arbitrary kernel memory access and a root shell.

Because epoll is a core kernel facility used by almost every process, the bug needs nothing unusual to reach. Any local unprivileged account can trigger it: a shell user, a cron job, or a web process that an attacker has already compromised.

A public proof-of-concept is available. Details: public PoC (J-jaeyoung/bad-epoll) · Red Hat CVE-2026-46242 · upstream fix (commit a6dc643c6931) · NVD entry for CVE-2026-46242

Status as of July 8, 2026, 15:00 UTC.

Patched AlmaLinux kernels for CloudLinux 9 and 10 are in the AlmaLinux testing repository. KernelCare livepatches are being prepared. See the Update Instructions below for per-platform status, and plan to apply the update as soon as it reaches your channel. This advisory is updated as patches move to stable channels.

The same kernel update also fixes Januscape. The AlmaLinux kernels that close Bad epoll are the same builds that close the Januscape KVM vulnerability (CVE-2026-53359). One kernel update and one reboot cover both. See the Januscape advisory for details on that issue.

Affected CloudLinux versions

Version Kernel Affected by Bad epoll Patched via
CloudLinux 7 (CL7) 3.10 ✅ No n/a
CloudLinux 7h (CL7h) 4.18 ✅ No n/a
CloudLinux 8 (CL8) 4.18 ✅ No n/a
CloudLinux 8 LTS 4.18 (TuxCare ELS) ✅ No n/a
CloudLinux 9 (CL9) 5.14 ❌ Yes AlmaLinux kernel plus KernelCare livepatch
CloudLinux 9 LTS 5.14 (TuxCare ELS) ❌ Yes TuxCare ELS kernel plus KernelCare livepatch
CloudLinux 10 (CL10) 6.12 ❌ Yes AlmaLinux kernel plus KernelCare livepatch
CloudLinux for Ubuntu 22.04 LTS 5.15 ✅ No n/a

Legend: ✅ not affected · ❌ affected.

Is there a mitigation?

No. Unlike a loadable-module vulnerability, there is no workaround short of the kernel update. epoll is a core kernel facility and cannot be disabled, and per-tenant sandboxing such as CageFS does not block it, because every process uses epoll. The only fix is the patched kernel or a KernelCare livepatch. Apply Stream 1, 2, or 3 below as soon as it is available for your platform.

Update instructions

Three delivery streams cover the affected platforms.

Stream 1: AlmaLinux kernel (CL9, CL10)

Status: July 8, 2026, 15:00 UTC.

AlmaLinux has published patched kernels to its testing repository. Promotion to the production repositories follows. CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer. CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.

To install from the AlmaLinux testing repository now, enable it by installing the release-testing package directly from the AlmaLinux repo, update the kernel, then disable the testing repo again.

For CL10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

For CL9:

rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

Once the kernels reach the production repositories, a plain dnf update kernel; reboot is sufficient.

Stream 2: TuxCare ELS LTS kernel (CL9 LTS)

Status: July 8, 2026, 15:00 UTC.

The patched kernel-lts package for CloudLinux 9 LTS is being prepared. Target versions will be added here on release.

ELS-subscribed customers install from the TuxCare ELS repository.

yum update kernel-lts
reboot

Stream 3: KernelCare livepatch (all affected versions)

Update: July 10, 2026, 17:00 UTC.

KernelCare livepatch rollout:

  • In the testing feed: CloudLinux 10.
  • Still in preparation: CloudLinux 9 and CloudLinux 9 LTS.

Status: July 8, 2026, 15:00 UTC.

KernelCare livepatches for Bad epoll (CVE-2026-46242) are in development. Once released to the main feed, subscribed servers receive the patch automatically on the next update cycle.

Once available, deploy from the testing feed:

kcarectl --update --prefix test

Once promoted to the main feed, subscribed servers update automatically, or on demand:

kcarectl --update

How to verify you are patched

Streams 1 and 2 (kernel update). After updating and rebooting, compare your running kernel against the target version in the relevant stream’s most recent status callout above:

uname -r

Stream 3 (KernelCare). Once the livepatch is released:

kcarectl --patch-info | grep CVE-2026-46242

⚠ Do not use kcarectl –info | grep CVE-… for verification. That form returns empty output even on correctly patched systems. Always use kcarectl –patch-info for CVE-level status.

References

Comments

Leave a comment

Please log in to leave a comment. Published comments are visible to everyone.


Log in

Preguntas frecuentes

What is CVE-2026-46242?
In the Linux kernel, the following vulnerability has been resolved: eventpoll: fix ep_remove struct eventpoll / struct file UAF ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free(). For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory. In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache. Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs. If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there. A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.
Is CVE-2026-46242 being exploited in the wild?
No confirmed exploitation is recorded. The EPSS model estimates a 3.15% probability of exploitation within the next 30 days — patch on your normal schedule.
How do I fix CVE-2026-46242?
Update CloudLinux to the patched release.Then confirm the running version matches the patched release listed above.
Why does this advisory list several CVEs?
One vendor release fixed multiple vulnerabilities. This advisory covers CVE-2026-46242, CVE-2026-53359 — updating to the patched release resolves all of them at once.

Comprueba tu sistema en busca de vulnerabilidades

Selecciona tu producto y sistema operativo para ver los comandos de corrección exactos que se aplican a ti.

Comprueba tu sistema