CVE-2026-43074

What it actually does

This is a local use-after-free vulnerability in the Linux kernel eventpoll implementation. Under concurrent epoll-related operations, ep_free() can free a struct eventpoll object while another thread is still using it. If an attacker can reliably trigger and shape this race condition from a local unprivileged context, the stale kernel pointer may be reused, potentially allowing kernel memory corruption. Because the flaw is in kernel space, successful exploitation can lead to local privilege escalation, arbitrary kernel memory access or modification, system compromise, or a kernel crash.

Why it matters to the business

A user or process that already has local access to a Linux system may be able to elevate privileges to root or disrupt the host. This is most relevant for multi-user systems, shared hosting, developer workstations, containers with kernel attack surface exposure, and servers where an attacker may first gain a low-privileged foothold through another weakness. It is not known to be exploited in the wild, is not in the CISA KEV catalog, has low EPSS likelihood, and has no reported exploit maturity, but the high technical impact means exposed Linux fleets should still be patched through normal kernel maintenance cycles.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user or inside a workload that can exercise epoll syscalls against the host kernel. They then repeatedly create, modify, and tear down epoll instances across multiple threads to trigger the race where the kernel frees an eventpoll structure while it remains reachable by another execution path. If the attacker can win the race and influence subsequent heap allocation, the dangling reference may be redirected toward attacker-controlled or attacker-shaped memory. A reliable exploit would use that memory corruption to alter kernel control data or credentials, resulting in elevated privileges. Failed attempts may produce kernel warnings, KASAN use-after-free reports, general protection faults, or system instability.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix deferring eventpoll structure freeing through an RCU grace-period callback. Because no exact fixed versions were provided, use vendor advisories for the relevant distribution or kernel branch and apply the first kernel package that explicitly includes the CVE-2026-43074/eventpoll use-after-free fix. Reboot systems after kernel updates unless a validated live-patching mechanism confirms the fix is active. Where immediate patching is not possible, reduce local attack opportunities by limiting shell access, restricting untrusted workloads, enforcing container isolation, disabling unnecessary user accounts, and applying mandatory access controls such as SELinux or AppArmor. These mitigations reduce exposure but do not remove the underlying kernel flaw.

How to confirm the fix worked

Confirm that each system is running a vendor kernel version that includes the eventpoll RCU lifetime fix. Validate with distribution package metadata, kernel changelogs, security advisory references, or live-patch status rather than relying only on the upstream version number. After patching, reboot or verify that live patching has applied the relevant kernel object changes. Run vulnerability scans or configuration management checks across Linux assets to identify systems still on affected kernels. For high-assurance environments, verify that kernel source or vendor patch notes include the change that defers freeing of struct eventpoll via an RCU callback rather than direct kfree() during ep_free().

Typical attack path

1. Gain local code execution as an unprivileged user, service account, containerized process, or compromised application.
2. Exercise epoll/eventpoll functionality using concurrent threads and rapid create/delete/modify patterns.
3. Trigger the race condition in ep_free() so a struct eventpoll object is freed while still in use.
4. Attempt to reclaim or shape the freed kernel memory with controlled allocations.
5. Convert the use-after-free into kernel memory corruption.
6. Escalate privileges, modify kernel state, or crash the system if exploitation is unreliable.
7. Use elevated privileges to disable security controls, access protected data, or establish persistence.

How to detect it

There is no single reliable network indicator for this vulnerability because exploitation is local and occurs inside the kernel. Detection should focus on host telemetry, kernel logs, audit records, EDR events, and signs of local privilege escalation. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, and kernel oops reports for eventpoll- or epoll-related faults, use-after-free diagnostics, KASAN reports, RCU warnings, general protection faults, and panics. Correlate those events with process execution telemetry showing untrusted users or services rapidly creating multithreaded workloads, running unusual locally compiled binaries, or performing suspicious privilege changes. Also look for post-exploitation artifacts such as newly created root accounts, unexpected setuid files, changes to sudoers, disabled EDR/audit services, kernel module anomalies, or unexplained credential access. Absence of crash logs does not prove absence of exploitation, because a successful local privilege escalation may not crash the host.

• BUG: KASAN: use-after-free
• use-after-free in ep_free
• ep_free
• fs/eventpoll.c
• eventpoll
• general protection fault
• kernel BUG at fs/eventpoll.c
• Oops:
• RCU
• Unable to handle kernel NULL pointer dereference
• journalctl -k
• /var/log/kern.log
• /var/log/messages
• /proc/sys/kernel/core_pattern
• /var/crash/

What your security team should do

• Inventory Linux systems and identify kernels that do not include the eventpoll use-after-free fix.
• Prioritize patching internet-facing servers, multi-tenant systems, CI/CD runners, developer workstations, shared compute hosts, container platforms, and systems where untrusted users or workloads can execute code.
• Apply vendor kernel updates and reboot, or confirm a validated live patch is active.
• Review recent kernel logs for eventpoll, ep_free, use-after-free, KASAN, general protection fault, and unexplained kernel crash messages.
• Hunt for signs of local privilege escalation around the same timeframe as kernel instability, including unexpected root shells, new privileged users, suspicious setuid binaries, or security tooling being disabled.
• Harden local execution paths by limiting interactive access, constraining containers, and enforcing SELinux/AppArmor profiles.
• Track vendor advisories because exact fixed package versions vary by distribution and kernel stream.
• Treat confirmed exploitation as full host compromise and perform credential rotation, forensic preservation, and rebuild from trusted media if kernel-level compromise is suspected.