Contact us
Articles › Rocky Linux

Mitigating Bad Epoll (CVE-2026-46242, CVE-2026-43074) on Rocky Linux 9, 10, and LTS Variants

cvecve-2026-46242cve-2026-43074securitykerneleventpollepollrocky linuxltsmitigationtroubleshooting

Arsalan Zaidi
Customer Support Engineer

Jul 08, 2026

Introduction

Bad Epoll is a pair of local privilege escalation (LPE) vulnerabilities in the Linux kernel's eventpoll subsystem (fs/eventpoll.c):

  • CVE-2026-46242 (CVSS 3.1: 7.0, Important) is a use-after-free in ep_remove(). Two concurrent close() calls race: one frees a struct eventpoll (kmalloc-192) while the other still writes into it via hlist_del_rcu(), producing an attacker-controllable 8-byte UAF write. The upstream fix pins struct file via epi_fget() so the eventpoll cannot be freed during removal.
  • CVE-2026-43074 (CVSS 3.1: 7.3, Moderate) is a use-after-free in ep_get_upwards_depth_proc(). Closing an ancestor epoll fd races with adding a nested epoll fd, and ep_free() calls kfree() on the eventpoll while a concurrent thread still walks it under RCU. The upstream fix replaces kfree(ep) with kfree_rcu(ep, rcu) so the free is deferred past the RCU grace period.

Both vulnerabilities trace to the same root cause commit, 58c9b016e128 ("epoll: use refcount to reduce ep_mutex contention"), which changed the eventpoll lifetime model in v6.4-rc1. Public proof-of-concept exploit code exists for both CVEs, and each can produce a root shell from an unprivileged local user on a vulnerable kernel.

This article covers Rocky Linux 9 and 10, including CIQ RLC Pro, RLC Pro LTS, FIPS, and SIG/Cloud Next variants. Rocky Linux 8 and all el8 variants are not affected.

Problem

The eventpoll subsystem is a core kernel feature used by virtually every networked application (nginx, PostgreSQL, systemd, SSH). Unlike module-based vulnerabilities where the attack surface can be removed by blocking a kernel module, epoll is compiled into the kernel and cannot be disabled. Any system running an affected kernel version is vulnerable to local exploitation.

Both exploits require only local unprivileged access. They do not require any special capabilities, user namespaces, or kernel module loads. The attack runs entirely in userspace via standard syscalls (epoll_create, epoll_ctl, close, fork). This makes the attack surface broader than module-dependent CVEs like Dirty Frag or Pedit COW, where blocking the vulnerable module is a viable interim measure.

Treat the following as affected unless they are running a patched kernel (see Status):

  • Rocky Linux 9 and 10 community releases
  • RLC Pro LTS 9.2, 9.4, and 9.6
  • RLC Pro 9 and RLC Pro 10
  • RLC Pro FIPS variants built on el9 or el10 kernels
  • RLC Pro Hardened variants built on el9 or el10 kernels
  • CIQ SIG/Cloud Next 9 and 10
  • CIQ Linux Kernel LT 6.12

Rocky Linux 8, all el8 LTS variants (8.6, 8.8, 8.10), RLC Pro 8, FIPS 8.x, and CIQ Bridge / CentOS 7 are not affected. The vulnerable code path was introduced in kernel v6.4-rc1 and was not backported to the 4.18 kernel series.

Status

  • Fix status (el10): Upstream fixes have landed in mainline. The el10_2 kernel (kernel-6.12.0-211.31.1.el10_2) includes fixes for both CVEs and was released 2026-07-08. Community Rocky Linux 10 users can update from BaseOS once the rebuild is available.
  • Fix status (el9): No fix has been released for el9 yet. The upstream fixes target the 6.x kernel branches. Backporting to the 5.14-based el9 kernel is pending.
  • CIQ variant patches: CIQ has not yet published advisories for either CVE. Patched kernels for RLC Pro, LTS, FIPS, and SIG/Cloud Next variants are pending engineering builds. This article will be updated with exact NVRs as they become available.
  • No kernel-level mitigation available. Unlike module-based vulnerabilities, epoll is a built-in kernel subsystem that cannot be disabled or blocked. There is no sysctl, modprobe override, or configuration change that mitigates these CVEs at the kernel level. The only remediation is installing a patched kernel and rebooting. Operational controls (restricting local access, auditing accounts) can reduce exposure until the patch is applied.
  • Recommended action: For el10 systems, install the patched kernel as soon as it is available in your variant's repository and reboot. For el9 systems, prioritize patching once CIQ or community builds ship. Systems with local shell users, CI/CD runners, shared application accounts, or workloads that execute untrusted code should be treated as highest priority.
  • Open a support case if you need help assessing exposure across your fleet or tracking patched kernel availability for a specific CIQ variant.

Patched Kernels

Variant Patched Kernel Version Released
Rocky Linux 10.2 (Community) kernel-6.12.0-211.31.1.el10_2 2026-07-08

CIQ patched kernel NVRs for RLC Pro, LTS, FIPS, and SIG/Cloud Next variants will be added to this table as CIQ advisories are published. el9 variants are pending upstream backport.

Confirm what is running on a given system with:

uname -r

If your system reports the patched version above (or newer), the fix is in place.

Installing the Update

Rocky Linux 10 (Community)

For Rocky Linux 10.2 community edition, the patched kernel is available from the standard BaseOS repository once the Rocky rebuild is published. No additional repository configuration is required:

sudo dnf update kernel*
sudo reboot

RLC Pro 10, CIQ SIG/Cloud Next 10

Once the CIQ-built patched kernel is available, refresh metadata and update:

sudo dnf clean all && sudo dnf makecache
sudo dnf update kernel*
sudo reboot

el9 Variants (All)

No patched kernel is available for el9 at this time. This section will be updated when CIQ or community builds ship.

Verification

After installing the patched kernel and rebooting, confirm the running kernel:

uname -r

The output should match the patched version listed in the Patched Kernels table for your variant.

Resolution

Install the patched kernel for your variant and reboot:

sudo dnf update kernel*
sudo reboot

After rebooting, verify the running kernel matches the patched version:

uname -r

No mitigation was applied for these CVEs, so there is nothing to revert.

Notes

  • No kernel-level interim mitigation exists. Epoll is compiled into the kernel (CONFIG_EPOLL=y on all standard configurations) and cannot be disabled, blocked, or restricted without a patched kernel. This contrasts with module-based CVEs like Dirty Frag (where blocking esp4/esp6 is effective) or Pedit COW (where blocking act_pedit works). For systems that cannot be patched immediately, reducing local access exposure is the primary compensating control: restrict SSH access, audit local accounts, and limit workloads that execute untrusted code.
  • x86_64 exploits only, but the vulnerability is architecture-independent. The published PoCs target x86_64 with architecture-specific ROP chains. The underlying kernel bug exists on all architectures, so aarch64 and other platforms should also be patched, even though no public aarch64 exploit exists at this time.
  • Public exploit availability. Working exploits for both CVEs are publicly available on GitHub. Treat affected systems with local users or untrusted workloads as exploitable now.
  • el8 is safe. The vulnerable code was introduced in kernel v6.4-rc1 (58c9b016e128). The el8 kernel (4.18.x) does not contain this commit and is not affected.

References & related articles