CVE-2026-43074, the Linux eventpoll UAF Behind an RCU Fix

CVE-2026-43074 is a Linux kernel vulnerability in fs/eventpoll.c, the file behind Linux epoll. The official description is short, but the bug class is not trivial: in certain situations, ep_free() could free a struct eventpoll while another concurrent thread could still be using it through epi->ep. The upstream fix changes the object lifetime rule by delaying the final free through an RCU callback, instead of immediately calling kfree() on the eventpoll object. NVD records the CNA score from kernel.org as CVSS 3.1 7.8 High with local attack vector, low privileges required, no user interaction, unchanged scope, and high confidentiality, integrity, and availability impact. (NVD)

That combination is the right way to think about the risk. CVE-2026-43074 is not a remote network entry point by itself. It matters when an attacker, untrusted workload, compromised dependency, sandboxed process, container workload, CI job, or low-privileged local account can execute code on a Linux system whose kernel still carries the vulnerable eventpoll lifetime behavior. In that world, a “local” kernel vulnerability is not a footnote. It can become the difference between a contained foothold and host-level compromise.

Quick facts

Campo	Practical meaning
ID DO CVE	CVE-2026-43074
Affected component	Linux kernel fs/eventpoll.c, the eventpoll implementation behind epoll
Bug shape	Object lifetime bug described by upstream as a use-after-free prevention issue involving struct eventpoll
Official fix idea	Defer freeing struct eventpoll until after an RCU grace period
Upstream code change	Add struct rcu_head rcu para struct eventpoll and replace immediate kfree(ep) com kfree_rcu(ep, rcu) in the patched path
CVSS 3.1 from kernel.org CNA	7.8 High, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attacker position	Local low-privileged code execution, not unauthenticated remote access
Defesa primária	Install the fixed vendor kernel and make sure the system actually reboots into it
Highest-priority environments	CI runners, Kubernetes workers, shared Linux hosts, developer workstations, sandbox-heavy systems, and any host that runs untrusted local code
Bad validation habit	Running public kernel exploit code on production hosts instead of checking vendor advisory status, package status, patch lineage, and reboot state

The short advisory sentence hides a kernel engineering lesson: memory safety in concurrent kernel code is rarely just about whether an object is eventually freed. It is about who may still observe the object, through which pointer, under which lock or read-side critical section, and what guarantee exists before memory is returned to the allocator.

Why eventpoll risk is not niche

epoll is one of the standard Linux mechanisms for scalable event notification. Servers use it to watch many sockets. Proxies, browsers, databases, message brokers, containerized services, language runtimes, async frameworks, and local development tools depend on it directly or indirectly. It is part of the normal Linux execution environment, not an optional feature that defenders can safely disable across a fleet.

That creates two practical consequences. First, eventpoll code is reachable from ordinary programs. A vulnerability in this area does not require an exotic device, rare driver, or specialized hardware feature. Second, epoll activity is too normal to be a clean detection signal. Seeing a process call epoll_create1, epoll_ctlou epoll_wait does not mean it is exploiting CVE-2026-43074. It usually means the process is doing normal Linux I/O.

The security question is therefore not “Can I block epoll?” In most environments, the answer is no. The real questions are: Which systems run affected kernel streams? Which of those systems execute untrusted or semi-trusted local code? Which have already installed a fixed kernel package? Which have actually rebooted into that fixed kernel? Which hosts are shared enforcement boundaries for other workloads?

That last phrase matters. A Kubernetes worker is a shared enforcement boundary. A multi-tenant CI runner is a shared enforcement boundary. A browser sandbox depends on the kernel as a final boundary. A developer laptop that runs dependency install scripts and holds production credentials is also a meaningful boundary. Local kernel privilege escalation bugs become urgent when the local code is not fully trusted.

What the official record says

NVD’s description for CVE-2026-43074 states that Linux resolved the issue by changing eventpoll freeing behavior: in certain situations, ep_free() em eventpoll.c poderia kfree the epi->ep eventpoll structure while it was still being used by another concurrent thread, so the fix defers the free to an RCU callback to prevent use-after-free. NVD also notes that its own CVSS assessment was not yet provided on the page, while the kernel.org CNA score was 7.8 High with local attack vector and high impact across confidentiality, integrity, and availability. (NVD)

The patch text is small but revealing. The AUTOSEL patch shown through Patchew lists fs/eventpoll.c as the changed file, adds an rcu_head field to struct eventpoll, and changes the final free path from kfree(ep) para kfree_rcu(ep, rcu). The patch comment says ep_get_upwards_depth_proc() may still hold epi->ep under RCU. (Patchew)

That is the center of the bug: a pointer to an eventpoll object can remain visible to an RCU-protected walk after another path has decided to release the object. Immediate freeing violates the lifetime expectation of that concurrent reader. Delayed freeing makes the object memory remain valid until readers that could still hold the old pointer have finished.

The object lifetime problem in plain kernel terms

A kernel object lifetime bug is not always a simple “free twice” or “forget to free” mistake. In concurrent kernel code, the dangerous pattern is often more subtle:

1. Thread A decides an object is no longer needed.
2. Thread A removes references it owns.
3. Thread A frees the memory.
4. Thread B, already inside a read-side path or critical section, still has a way to reach the object.
5. Thread B dereferences memory that may now be released, reused, or partially overwritten.

In user-space code, that might show up as a crash under AddressSanitizer. In kernel code, the result can be a use-after-free, memory corruption, information leak, system crash, or, under the right conditions, a privilege escalation primitive. Not every use-after-free becomes a practical exploit, but defenders should not assume “hard to exploit” means “safe to ignore,” especially when the affected component sits in the shared kernel boundary.

The RCU part matters because RCU is designed for exactly this family of read-mostly concurrency patterns. A writer can remove or replace a pointer, but it must not immediately free the old object if readers may still be traversing it. The writer waits for a grace period, after which pre-existing readers are guaranteed to have exited their RCU read-side critical sections. Only then is it safe to reclaim the object memory.

For CVE-2026-43074, the key fix is not a new permission check, not input validation, and not a syscall blocklist. It is a lifetime guarantee: keep the eventpoll object memory around long enough that RCU readers are no longer using it.

Why the patch is small but security-significant

Small kernel patches often make security teams nervous because they look too simple for a high-impact CVE. That is a mistake. In concurrent systems, a one-line memory reclamation change can close a real vulnerability if it restores the missing ownership rule.

The relevant patch shape is easy to summarize:

struct eventpoll {
        ...
        refcount_t refcount;
        struct rcu_head rcu;
        ...
};

static void ep_free(struct eventpoll *ep)
{
        ...
        /* ep_get_upwards_depth_proc() may still hold epi->ep under RCU */
        kfree_rcu(ep, rcu);
}

This is not intended as a complete kernel patch; it is the important idea visible in the upstream diff. The old behavior freed the eventpoll object immediately. The new behavior arranges for the object to be freed only after the RCU grace period. In security terms, the patch moves the object from “released when this cleanup function decides it is done” to “released when concurrent RCU readers can no longer legally hold the pointer.”

That distinction is exactly why some concurrency bugs are hard to triage with crash-only thinking. If the timing window does not fire during testing, the host may look stable. If a sanitizer build does not observe the right interleaving, the issue may stay quiet. If a scanner only looks for package names without reboot state, it may declare a host fixed while the vulnerable kernel is still running.

Affected versions and fixed streams

OSV lists CVE-2026-43074 as published on May 6, 2026, with severity 7.8 High and the same CVSS vector. Its affected ranges give a useful upstream view: Linux kernel 6.4.0 to before 6.6.136, 6.7.0 to before 6.12.83, 6.13.0 to before 6.18.24, and 6.19.0 to before 6.19.14 are listed as affected ranges, with fixed versions at 6.6.136, 6.12.83, 6.18.24, and 6.19.14 respectively. (test.osv.dev)

NVD’s change history similarly records kernel.org affected-version data and marks versions earlier than 6.4 as unaffected, with fixed status for the listed stable streams and an original fix status for the later upstream line. (NVD)

Kernel stream view	Affected range shown by OSV	Fixed version shown by OSV	What defenders should do
6.4 and 6.6 stable lineage	6.4.0 through versions before 6.6.136	6.6.136	Check whether your distribution backported the fix, then reboot into the fixed kernel
6.7 through 6.12 lineage	6.7.0 through versions before 6.12.83	6.12.83	Treat shared execution hosts as high priority
6.13 through 6.18 lineage	6.13.0 through versions before 6.18.24	6.18.24	Verify package status and running-kernel status separately
6.19 lineage	6.19.0 through versions before 6.19.14	6.19.14	Do not rely on uname -r alone if the vendor uses backports
Distribution kernels	Vendor-specific	Vendor-specific	Follow the vendor advisory, changelog, and package metadata

The distribution angle is important. Enterprise Linux vendors routinely backport security fixes without changing to the exact upstream version number that appears in a generic CVE database. A system can show a kernel version lower than an upstream fixed version while still carrying the fix. The reverse can also happen in custom kernels, downstream images, appliance builds, or container-optimized kernels: the version string alone may not prove that the relevant commit is present.

Amazon Linux’s security center, for example, records CVE-2026-43074 as Important with CVSS v3 base score 7.8, marks Amazon Linux 2 kernel streams and the default Amazon Linux 2023 kernel as not affected, and lists fixed status for Amazon Linux 2023 kernel6.12 e kernel6.18 advisories released on May 9, 2026. (AWS Explore) Red Hat’s public Bugzilla entry mirrors the upstream description and shows Red Hat errata activity for RHEL-related products in July 2026. (Red Hat Bugzilla)

That is why serious validation needs three separate fields: the running kernel, the installed fixed package, and the vendor advisory status for the exact distribution and kernel stream.

Why CVSS says local but the risk can still be high

The CVSS vector for CVE-2026-43074 begins with AV:L, which means the attacker needs local access to the vulnerable system. That often leads to a bad shortcut: “local equals low priority.” For kernel bugs, that shortcut is wrong.

Local code execution is common in modern infrastructure. A CI runner executes build scripts and test code. A package manager runs install hooks. A developer workstation runs browser content, IDE extensions, local AI assistants, test binaries, language servers, and open-source tools. A Kubernetes worker runs containers from different services and sometimes different trust zones. A shared Linux host may run workloads from several users. A browser renderer or app sandbox may be attacker-controlled after a separate bug.

In those environments, the kernel is the shared enforcement layer. If the kernel boundary fails, higher-level isolation can collapse. That is why a local kernel privilege escalation bug can be more urgent on a CI worker than on a single-purpose appliance that never runs untrusted local code.

A practical priority model should look like this:

Meio ambiente	Why CVE-2026-43074 matters	Patch priority
Multi-tenant CI runner	Pull requests, dependency scripts, and build jobs may execute code that is not fully trusted	Muito alto
Kubernetes worker with mixed-trust workloads	Containers share the host kernel, so kernel bugs threaten workload isolation	Muito alto
Developer workstation	Local tools, package scripts, browser content, and secrets create post-foothold escalation risk	Alta
Shared research or shell server	Low-privileged users already have local execution	Alta
Browser-heavy workstation	A renderer foothold may become more serious if paired with a kernel local bug	Alta
Single-purpose internal server with no untrusted local code	Exposure depends on whether another bug can produce local code execution	Médio
Fully isolated lab host	Operational impact may be lower, but patching is still correct	Normal maintenance unless exposed

What exploitation would require, and what should not be assumed

The official CVE record does not provide a public weaponized exploit chain for CVE-2026-43074. It describes the memory lifetime bug and the fix. That distinction matters. A defender should not inflate the known facts into claims that every affected kernel is trivially rootable. At the same time, a defender should not dismiss the issue just because the public record is short.

A kernel object lifetime bug becomes exploitable only if the attacker can do more than trigger a stale pointer. A practical exploit usually needs some combination of controllable timing, heap shaping, useful reuse of freed memory, bypasses for kernel hardening, and a post-corruption primitive that can affect credentials, control flow, file operations, or another privileged object. Those details are target-specific and not necessary for routine remediation.

For security operations, the useful distinction is simpler:

Pergunta	Useful answer for remediation
Is the bug local or remote?	Local. Prioritize systems that run untrusted local code.
Does it require privileges?	The CNA vector says low privileges required.
Is user interaction required?	The CNA vector says no user interaction.
Can epoll be disabled safely?	Not generally. Too much software depends on it.
Should teams run exploit code to validate?	Usually no. Use vendor status, package status, reboot status, and controlled lab testing only when authorized.
Is the fix available upstream?	Yes, fixed stable streams and patch references are recorded by NVD and OSV.
Is a reboot required?	For ordinary kernel package updates, yes, unless a vendor live patch specifically covers the issue and your policy accepts it.

The absence of a public exploit is not proof of safety. The presence of a public exploit for a related bug is not proof that this specific CVE has the same exploitability. Keep those two ideas separate.

Safe validation without exploit code

A safe validation workflow should answer whether a host is exposed, whether a fix is installed, and whether the fixed kernel is running. It should not depend on running a kernel exploit on production.

Start with local inventory:

# Record the running kernel.
uname -r

# Record OS identity and version.
cat /etc/os-release

# Record boot time, useful for proving whether a reboot happened after patching.
uptime -s 2>/dev/null || who -b

# Keep package evidence. Exact commands vary by distribution.

For Debian and Ubuntu families, the package names vary by kernel flavor, but these commands help collect the right evidence:

# Debian and Ubuntu style inventory.
dpkg -l 'linux-image*' | awk '/^ii/ {print $2, $3}'

# Show candidate and installed package metadata for the running kernel package when available.
apt-cache policy "linux-image-$(uname -r)" || true

# Search changelog text for the CVE if package changelogs are installed or available.
apt changelog "linux-image-$(uname -r)" 2>/dev/null | grep -i 'CVE-2026-43074' -C 3 || true

For RHEL, Fedora, CentOS Stream, Rocky, AlmaLinux, and other DNF-based systems, use advisory metadata where available:

# DNF-based advisory query.
sudo dnf updateinfo info --cve CVE-2026-43074 || true

# Installed kernel packages.
rpm -qa 'kernel*' | sort

# Running kernel.
uname -r

For SUSE and openSUSE systems:

# SUSE advisory query.
sudo zypper lp --cve CVE-2026-43074 || true

# Installed kernel packages.
rpm -qa 'kernel*' | sort

# Running kernel.
uname -r

For Amazon Linux, follow the Amazon Linux Security Center advisory status for the relevant kernel stream, then confirm the installed and running kernel. Amazon’s public page distinguishes not-affected streams from fixed kernel6.12 e kernel6.18 streams, which is exactly the kind of vendor-specific status that generic version checks can miss. (AWS Explore)

The minimum evidence set should look like this:

Evidence field	Por que é importante
Asset ID and hostname	Ties remediation to a real system
Distribution and release	Determines the correct vendor advisory source
Running kernel before patch	Shows current exposure state
Installed kernel package version	Shows whether the fix was installed
Running kernel after reboot	Shows whether remediation is active
Vendor advisory or errata ID	Links the decision to an authoritative source
Local-code exposure rating	Explains patch priority
Workload owner	Needed for reboot coordination
Exception owner and expiry	Prevents indefinite “accepted risk” drift

Many failed kernel remediation programs install the fixed package and stop there. That is not enough. The vulnerable kernel can remain active until reboot. For high-risk hosts, the evidence that matters is the post-reboot running kernel, not merely package installation.

A safe PoC for understanding the bug class

The following demonstration is not an exploit for CVE-2026-43074. It does not call Linux epoll, does not touch fs/eventpoll.c, does not attempt privilege escalation, and does not target any real system. It is a local toy program that shows the underlying lifetime mistake: one thread frees an object while another thread still has a pointer to it.

Run it only in a local disposable development environment. Compile it with AddressSanitizer so the memory error is detected by the runtime instead of being used for anything useful.

// uaf_lifetime_demo.c
// Educational toy example only.
// This is NOT a CVE-2026-43074 exploit and does not interact with Linux eventpoll.

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

struct watched_object {
    int value;
};

static struct watched_object *global_obj;

void *reader_thread(void *unused) {
    (void)unused;

    // Simulate a reader that obtains a pointer and keeps using it later.
    struct watched_object *local = global_obj;

    // Give the writer time to free the object.
    usleep(100000);

    // Dangerous: local may point to freed memory.
    // AddressSanitizer should report this as a heap-use-after-free.
    printf("reader saw value: %d\n", local->value);
    return NULL;
}

void *writer_thread(void *unused) {
    (void)unused;

    // Simulate a cleanup path that frees the object too early.
    usleep(20000);
    free(global_obj);
    global_obj = NULL;

    return NULL;
}

int main(void) {
    pthread_t r, w;

    global_obj = malloc(sizeof(*global_obj));
    if (!global_obj) {
        perror("malloc");
        return 1;
    }

    global_obj->value = 42;

    pthread_create(&r, NULL, reader_thread, NULL);
    pthread_create(&w, NULL, writer_thread, NULL);

    pthread_join(r, NULL);
    pthread_join(w, NULL);

    return 0;
}

Compile and run it locally:

clang -O0 -g -fsanitize=address -pthread uaf_lifetime_demo.c -o uaf_lifetime_demo
./uaf_lifetime_demo

Expected result: AddressSanitizer should report a heap-use-after-free or the program may terminate with sanitizer output. That is the safe lesson: the reader’s pointer can outlive the writer’s decision to free the object.

A safer lifetime model does not let the writer reclaim memory until readers that may hold the old pointer are done. The following sketch is not kernel RCU, but it illustrates the idea:

// Conceptual sketch only, not production synchronization code.

reader_enter();
struct watched_object *local = global_obj;

/*
 * Reader uses local while the lifetime system knows
 * at least one reader may still hold the old pointer.
 */

reader_exit();

/*
 * Writer removes the object from publication first,
 * then waits for pre-existing readers to leave before freeing.
 */

global_obj = NULL;
wait_for_readers_to_drain();
free(old_obj);

In the kernel, RCU provides a disciplined version of that pattern. The writer can remove a pointer, but the memory behind the old pointer must remain valid until the RCU grace period ends. CVE-2026-43074’s fix aligns eventpoll object reclamation with that rule.

Why production exploit testing is the wrong default

Kernel exploit testing can crash systems, corrupt state, interfere with endpoint controls, and create unclear evidence. A failed exploit run does not prove the system is fixed. It may only prove that the exploit did not match that kernel build, hardening profile, allocator behavior, CPU timing, or environment. A successful exploit run on production is even worse: it may violate policy, disrupt workloads, and create incident response obligations.

For routine operations, the safer validation path is:

1. Identify the kernel stream and distribution.
2. Check the vendor advisory for CVE-2026-43074.
3. Confirm whether the fixed package is installed.
4. Reboot or confirm a vendor-supported live patch.
5. Verify the running kernel after remediation.
6. Record evidence.
7. Prioritize remaining exceptions by local-code exposure.

Use exploit reproduction only in an isolated lab, with written authorization, controlled kernel versions, snapshots, and clear rules of engagement. Even then, keep the goal narrow: understand risk and confirm defensive assumptions, not produce a reusable weapon.

Detection limits

CVE-2026-43074 is not a clean network-detection problem. There is no HTTP path, TLS fingerprint, request header, or remote indicator that identifies it. It is also not practical to flag normal epoll usage, because epoll is everywhere.

Good detection and monitoring focus on exposure and failure signals, not syscall presence alone.

Sinal	Valor	Limitação
Kernel inventory	Best primary exposure signal	Must account for vendor backports
Vendor advisory status	Authoritative for supported distributions	Requires mapping assets to exact kernel stream
Reboot state	Proves whether a fixed kernel is active	Often missing from vulnerability scanners
Kernel oops or crash logs	May reveal instability in affected areas	Absence of crashes proves nothing
KASAN, KFENCE, or debug kernel findings	Useful in labs and fuzzing environments	Rarely enabled in production
EDR process telemetry	May show suspicious local execution chains	Does not identify CVE-2026-43074 directly
Container or CI workload provenance	Helps prioritize hosts	Does not prove kernel vulnerability by itself

Useful local log checks may include:

# Kernel messages from current boot.
dmesg -T | egrep -i 'BUG:|WARNING:|KASAN|KFENCE|use-after-free|eventpoll|epoll' || true

# Persistent journal entries where systemd-journald is used.
journalctl -k --since "7 days ago" | egrep -i 'BUG:|WARNING:|KASAN|KFENCE|use-after-free|eventpoll|epoll' || true

These commands are not vulnerability scanners. They only collect possible instability evidence. A system can be vulnerable without any log signal. A system can also have unrelated kernel warnings that mention memory safety terms. Treat logs as supporting context, not proof.

Fleet inventory with osquery

If osquery is deployed, it can help gather the evidence needed for triage. The exact schema available depends on your osquery version and platform, but the following style of query illustrates the goal:

SELECT
  hostname,
  version AS kernel_version,
  arguments AS kernel_arguments
FROM kernel_info;

Package inventory can then be joined with operating system metadata:

SELECT
  name,
  version,
  release,
  source
FROM rpm_packages
WHERE name LIKE 'kernel%';

For Debian-family systems:

SELECT
  name,
  version,
  source
FROM deb_packages
WHERE name LIKE 'linux-image%';

The key is not to ask osquery to “detect exploitation.” Ask it to collect reliable host facts at scale: kernel version, package version, OS release, boot time, and owner tags. Then map those facts to the vendor’s advisory.

Prioritizing remediation

A sensible remediation order should reflect execution trust, not just CVSS. CVE-2026-43074 has the same generic CVSS score across many systems, but the real operational risk varies sharply by workload.

Patch first:

Prioridade	Asset type	Reason
1	CI runners that execute pull requests or third-party build scripts	Untrusted local execution is routine
1	Kubernetes and container hosts with mixed-trust workloads	Containers share the host kernel
1	Shared shell, research, training, or bastion-like Linux hosts	Multiple low-privileged users may execute code
2	Developer workstations with production credentials	Local compromise can become credential compromise
2	Browser-heavy endpoints and VDI	Sandbox chains can make local kernel bugs valuable
2	Internet-facing app servers where app RCE would produce local code execution	Kernel LPE can turn app compromise into host compromise
3	Single-purpose internal servers with restricted local execution	Still patch, but schedule by change window
3	Isolated lab systems	Patch through standard maintenance unless exposed

For systems that cannot be patched immediately, reduce the chance that untrusted local code reaches them. Pause untrusted CI jobs on affected runners. Move mixed-trust workloads away from affected nodes. Restrict shell access. Reduce container privileges. Review seccomp, AppArmor, and SELinux profiles. Rotate secrets if an affected shared host ran untrusted code during the exposure window. These actions reduce risk while waiting for a patch window, but they do not replace the kernel update.

Hardening that helps, but does not replace the patch

Several controls can make kernel exploitation harder or reduce the blast radius of local code execution. None of them should be described as a complete workaround for CVE-2026-43074.

Controle	How it helps	Why it is not enough
Fast kernel patching and reboot discipline	Removes the vulnerable code path	Requires operational ownership and downtime planning
Seccomp profiles	Can reduce available syscall surface for tightly controlled workloads	Broadly blocking epoll breaks many applications
AppArmor or SELinux	Can constrain process behavior after compromise	Kernel bugs may cross policy expectations
Dropped container capabilities	Reduces easy post-exploitation actions	Containers still share the kernel
Read-only root filesystems	Limits persistence and tampering	Does not eliminate kernel memory corruption risk
CI workload isolation	Reduces exposure from untrusted code	Requires scheduling and cost tradeoffs
Secret minimization on hosts	Reduces impact after local escalation	Does not fix the vulnerability

The most common mistake is to treat hardening as a reason to delay patching indefinitely. Hardening is valuable because it buys time and reduces impact. It is not a substitute for correcting the object lifetime bug.

Why reboot status deserves its own control

Kernel patching often fails at the last step. Teams install updates but do not reboot. Scanners then show confusing results: the package database looks fixed, but the running kernel is still vulnerable.

Use a simple rule: for CVE-2026-43074, the remediation record is incomplete until the running kernel is proven fixed. That proof may be a reboot into a fixed kernel or a vendor-supported live patch explicitly covering the issue. Anything else is an interim state.

A remediation record should include:

Asset: ci-runner-prod-17
OS: Example Linux 2026
Running kernel before: 6.x.y-example
Vendor advisory: vendor advisory ID or URL
Fixed package installed: yes
Reboot completed: yes
Running kernel after: 6.x.y-fixed-build
Local-code exposure: high
Owner: platform engineering
Evidence captured by: security operations
Exception: none

That may look bureaucratic, but it prevents the most common kernel remediation failure: assuming installed equals active.

The sibling eventpoll lesson, Bad Epoll and CVE-2026-46242

CVE-2026-43074 became more interesting after public discussion of Bad Epoll, tracked separately as CVE-2026-46242. Bad Epoll is a different Linux eventpoll race-condition use-after-free that drew attention because public writeups described local root impact and Android relevance on certain kernel lineages. The Hacker News summarized Bad Epoll as a Linux kernel use-after-free race in epoll and noted that it is related to the same area of code where CVE-2026-43074 had been fixed earlier. (Notícias do Hacker)

The relationship is useful for defenders, but it should be framed carefully. CVE-2026-43074 and CVE-2026-46242 are not the same CVE. They are nearby eventpoll lifetime problems with separate fixes and separate operational tracking. The lesson is that one patch in a concurrency-heavy subsystem does not automatically prove that every adjacent race is gone.

Penligent’s technical writeup on Bad Epoll makes the same operational point: CVE-2026-43074 is directly relevant because it involved eventpoll object lifetime and an RCU-delayed free, while Bad Epoll showed that a related area could still contain a distinct lifetime issue requiring separate review and remediation. (Penligente)

For defenders, the practical result is simple: if you are reviewing exposure to one eventpoll race, review the sibling eventpoll advisories and fixes too. Do not rely on a vague statement like “we patched the epoll bug.” Identify which CVE, which vendor advisory, which package, which commit lineage, and which running kernel.

Related Linux kernel CVEs worth understanding

CVE-2026-43074 belongs to a broader operational class: Linux kernel vulnerabilities that may turn local code execution into a stronger host compromise. The details differ, but the prioritization logic often overlaps.

CVE	Subsystem	Bug shape	Attacker position	Why it helps explain CVE-2026-43074
CVE-2026-43074	fs/eventpoll.c	Eventpoll object lifetime issue fixed by RCU-delayed free	Local low-privileged code path	Shows why concurrent kernel object lifetime is security-critical
CVE-2026-46242, Bad Epoll	fs/eventpoll.c	Race-condition use-after-free in eventpoll cleanup paths	Local code execution	Shows that nearby eventpoll lifetime issues may require separate fixes
CVE-2026-31431, Copy Fail	Linux crypto algif_aead caminho	In-place operation complexity leading to page-cache corruption risk	Local unprivileged user	Shows how non-network kernel APIs can still create root escalation paths
CVE-2026-31694	FUSE	Oversized directory entry handling in page-cache path	Local context with FUSE relevance	Shows why user-reachable kernel interfaces matter in containers and namespaces
CVE-2022-0847, Dirty Pipe	Pipe and page-cache behavior	Page-cache overwrite primitive	Local unprivileged user	Historical reminder that local kernel primitives can become widely exploited

Microsoft described CVE-2026-31431, Copy Fail, as a Linux kernel crypto-subsystem bug that could let an unprivileged attacker corrupt the cache of readable files, including setuid binaries, and escalate to root. (Microsoft) NVD describes CVE-2026-31694 as a FUSE issue where a server-controlled directory entry length could exceed page-cache expectations. (NVD) NVD also records CVE-2022-0847, Dirty Pipe, as a Linux kernel privilege escalation vulnerability that entered CISA’s Known Exploited Vulnerabilities catalog in 2022. (NVD)

These CVEs should not be merged into one generic “Linux LPE” bucket. Their exploit primitives, affected versions, mitigations, and detection opportunities differ. What they share is the operational reality that local kernel bugs matter whenever the system runs code that is not fully trusted.

AI-assisted vulnerability discovery and validation

CVE-2026-43074 also sits inside a larger industry conversation about AI-assisted vulnerability research. Anthropic announced Project Glasswing in April 2026 and described Claude Mythos Preview as an unreleased frontier model used for defensive vulnerability discovery across critical software. Anthropic said Mythos Preview had found vulnerabilities in major operating systems and browsers, including Linux kernel vulnerability chains that could escalate privileges, and that reported examples had been patched. (Antrópica)

That context should not be turned into hype. AI systems can help researchers inspect patch diffs, propose invariants, generate test harness ideas, summarize vendor advisories, and correlate affected assets. They can also be wrong, incomplete, or overconfident. A concurrency vulnerability like CVE-2026-43074 still needs kernel expertise, patch review, runtime reasoning, and safe validation.

For defensive teams, the useful direction is evidence automation, not exploit automation. A good workflow records the hypothesis, affected subsystem, vendor advisory, package state, running kernel, reboot status, local-code exposure, and retest evidence. In authorized testing programs, platforms such as Penligent can help structure AI-assisted validation and evidence collection around approved assets, but the source of truth for Linux kernel exposure remains the relevant vendor advisory and the running kernel state, not a model’s confidence score. (Penligente)

Common mistakes in CVE-2026-43074 triage

The first mistake is relying only on uname -r. Kernel version strings are necessary but not sufficient. Distribution backports can carry a fix without matching the upstream fixed version exactly. Custom kernels can also diverge from upstream in ways that a simple version comparison cannot capture.

The second mistake is treating local as unimportant. Local code execution is not rare in CI, containers, developer workstations, shared hosts, and sandbox chains. If the host runs untrusted code, a local kernel bug is a boundary issue.

The third mistake is trying to detect exploitation by watching for epoll usage. That creates noise. Epoll is normal. Detection should focus on exposed assets, untrusted local execution, suspicious post-foothold activity, and kernel instability signals, not ordinary eventpoll syscalls.

The fourth mistake is declaring remediation complete before reboot. Kernel package installation and active kernel remediation are different states.

The fifth mistake is assuming one eventpoll fix covers every eventpoll race. CVE-2026-43074 and Bad Epoll show why adjacent bugs can share a design pressure without sharing a fix.

The sixth mistake is using production exploit runs as validation. Kernel UAF exploit attempts are not health checks. They are risky tests that belong, if anywhere, in isolated authorized labs.

Practical remediation workflow

A clean workflow for CVE-2026-43074 looks like this:

# 1. Identify the host and kernel.
hostname
cat /etc/os-release
uname -r
uptime -s 2>/dev/null || who -b

# 2. Query vendor advisory data.
# Use the command appropriate for your distribution.

# Debian or Ubuntu family
apt-cache policy "linux-image-$(uname -r)" || true
apt changelog "linux-image-$(uname -r)" 2>/dev/null | grep -i 'CVE-2026-43074' -C 3 || true

# DNF family
sudo dnf updateinfo info --cve CVE-2026-43074 || true

# SUSE family
sudo zypper lp --cve CVE-2026-43074 || true

# 3. Apply vendor kernel updates through normal change control.
# 4. Reboot, unless a vendor-supported live patch explicitly covers the issue.
# 5. Verify the running kernel after reboot.
uname -r
uptime -s 2>/dev/null || who -b

For fleets, this should become an asset query and change-management workflow rather than a manual shell exercise. The owner of the process should be able to answer, at any time, which affected systems remain unpatched, which are patched but not rebooted, which are blocked by maintenance windows, and which run untrusted local code.

What to do when immediate patching is blocked

Sometimes a critical host cannot be rebooted immediately. That is an operational fact, not a reason to ignore the issue. Use temporary exposure reduction while scheduling a real fix.

Good temporary actions include:

• Move untrusted workloads away from affected Kubernetes workers.
• Pause CI jobs from forks, untrusted branches, or external contributors on affected runners.
• Restrict shell access to affected shared hosts.
• Avoid running new third-party binaries, package scripts, or experimental tooling on affected developer machines.
• Tighten container profiles by dropping unnecessary capabilities and applying seccomp, AppArmor, or SELinux policies.
• Reduce secrets present on affected shared hosts.
• Add an exception record with an owner and expiration date.
• Schedule a reboot into the fixed kernel.

Bad temporary actions include:

• Claiming epoll can be disabled fleet-wide.
• Treating a failed public exploit as proof of safety.
• Leaving patched-but-not-rebooted systems in a “fixed” state.
• Ignoring CI and container hosts because the CVSS vector says local.
• Waiting for signs of exploitation before patching a shared execution boundary.

PERGUNTAS FREQUENTES

What is CVE-2026-43074?

• CVE-2026-43074 is a Linux kernel vulnerability in fs/eventpoll.c, the eventpoll implementation behind epoll.
• The official description says ep_free() could free a struct eventpoll while another concurrent thread could still be using it.
• The fix defers freeing the eventpoll object through an RCU callback, reducing the risk of a use-after-free.
• The kernel.org CNA score shown by NVD is CVSS 3.1 7.8 High.

Is CVE-2026-43074 remotely exploitable?

• The recorded CVSS vector uses local attack vector, AV:L.
• The attacker needs some ability to run code locally on the affected system.
• It should not be described as a standalone unauthenticated remote exploit.
• It still matters for servers if another vulnerability, compromised account, malicious dependency, CI job, container workload, or sandbox escape gives an attacker local execution.

Which Linux kernel versions are affected?

• OSV lists affected upstream ranges beginning at 6.4.0, 6.7.0, 6.13.0, and 6.19.0, with fixed versions 6.6.136, 6.12.83, 6.18.24, and 6.19.14 respectively.
• NVD’s kernel.org data also marks versions before 6.4 as unaffected and records fixed stable streams.
• Distribution backports may fix the issue without matching the exact upstream version number.
• Use your vendor advisory and package metadata for final production decisions.

How do I verify whether a system is fixed without running exploit code?

• Record the running kernel with uname -r.
• Identify the OS and distribution release with /etc/os-release.
• Query vendor advisory metadata, such as dnf updateinfo, zypper lp, or distribution security trackers.
• Confirm the fixed kernel package is installed.
• Reboot and verify the running kernel changed.
• Preserve evidence: host ID, OS release, package version, running kernel before and after reboot, advisory reference, and owner.

Can I disable epoll as a workaround?

• There is no practical general-purpose workaround that safely disables epoll across normal Linux systems.
• Many servers, browsers, runtimes, databases, proxies, and async frameworks depend on epoll.
• Narrow syscall restrictions may help for very controlled workloads, but broad epoll blocking will break applications.
• The reliable fix is a vendor kernel update plus reboot or a vendor-supported live patch that explicitly covers the issue.

Why does the RCU grace period matter?

• RCU lets readers safely traverse objects while writers remove or replace references.
• A writer must not free memory immediately if existing RCU readers may still hold a pointer.
• CVE-2026-43074’s fix delays freeing struct eventpoll so readers that may still hold epi->ep can finish first.
• The security benefit is a stronger object lifetime guarantee, not a new access-control rule.

How is CVE-2026-43074 related to Bad Epoll?

• Both involve Linux eventpoll object lifetime and race-condition risk, but they are separate CVEs.
• CVE-2026-43074 was fixed by delaying struct eventpoll freeing through RCU.
• Bad Epoll, CVE-2026-46242, is a separate eventpoll race-condition use-after-free discussed publicly as a local privilege escalation issue.
• Defenders should track both separately and avoid assuming one eventpoll patch covers every related race.

What should be patched first in a real fleet?

• Patch CI runners, Kubernetes workers, shared Linux hosts, and developer workstations first if they run untrusted or semi-trusted local code.
• Patch internet-facing app servers quickly if an application compromise could give attackers a local process.
• Patch lower-exposure single-purpose systems through normal maintenance, but keep an owner and deadline.
• Always confirm reboot state or live-patch coverage before marking remediation complete.

The practical call

CVE-2026-43074 is a compact advisory for a serious class of kernel bug: object lifetime failure under concurrency. The fix is small because the missing rule is precise. The eventpoll object must not be reclaimed while an RCU-protected path may still hold it.

Handle the vulnerability with the same discipline you would apply to any kernel boundary issue. Map affected kernel streams to vendor advisories. Identify systems that run untrusted local code. Install fixed kernel packages. Reboot into the fixed kernel. Keep evidence. Treat CI runners, container hosts, shared Linux systems, and developer machines as higher priority than isolated single-purpose hosts.

The correct response is not panic and not dismissal. It is careful kernel inventory, patch verification, reboot proof, and a clear understanding that “local” does not mean “low risk” when the local code is not fully trusted.