Contact us
Articles › Security Advisories

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 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
  • CIQ Linux Kernel 6.18

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

  • Patched kernels are available. See the Patched Kernels table below for exact NVRs and release dates.
  • 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: Install the patched kernel for your variant and reboot. 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 Repo Released
RLC Pro LTS 9.2 kernel-5.14.0-284.30.1+35.1.el9_2_ciq rlc-9.2-lts.x86_64 2026-07-15
RLC Pro LTS 9.6 kernel-5.14.0-570.60.1+18.1.el9_6_ciq rlc-9.6-lts.x86_64 2026-07-14
RLC Pro FIPS 9.2 kernel-5.14.0-284.30.1+35.1.el9_2_ciq fips-9.2-compliant-x86_64 2026-07-15
RLC Pro FIPS 9.6 kernel-5.14.0-570.60.1+18.1.el9_6_ciq fips-9.6-compliant-x86_64 2026-07-14
RLC Pro 9 kernel-5.14.0-687.24.1+2.1.el9_8_ciq rlc-pro-9.x86_64 2026-07-16
CIQ SIG/Cloud Next 9 kernel-5.14.0-687.24.1+2.1.el9_8_ciq ciq-sigcloud-next-9.x86_64 2026-07-16
CIQ Linux Kernel LT 6.12 kernel-clk6.12-6.12.95-1.1.el9_clk clk-6.12-el9.x86_64 2026-07-09
CIQ Linux Kernel 6.18 kernel-clk6.18-6.18.38-2.1.el9_clk clk-6.18-el9.x86_64 2026-07-15
RLC Pro 10 kernel-6.12.0-211.32.1+2.1.el10_2_ciq rlc-pro-10.x86_64 2026-07-16
CIQ SIG/Cloud Next 10 kernel-6.12.0-211.32.1+2.1.el10_2_ciq ciq-scn-10.x86_64 2026-07-16

CIQ updates this table as tested kernels become available for each variant.

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

RLC Pro LTS, FIPS, RLC Pro, and SIG/Cloud Next

sudo dnf update kernel*

Reboot into the new kernel after the update completes. No additional repository configuration is needed; the update is available from the configured CIQ repository. If the update does not appear, run sudo dnf clean all && sudo dnf makecache to refresh repository metadata.

CIQ Linux Kernel (CLK) Variants

sudo dnf update kernel-clk*

Reboot into the new kernel.

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