CVE-2026-43366

What it actually does

This is a local Linux kernel race condition in the io_uring provided-buffer recycling path. A process with local user-level code execution can trigger a timing window where a buffer is captured for use, the associated buffer list is changed from the legacy type to a ring-provided type, and the kernel later attempts legacy recycling without revalidating that the buffer list still exists and is still the expected type. That stale or mismatched state can lead to memory corruption or invalid kernel object handling. Because the flaw is in kernel context and the CVSS vector indicates high confidentiality, integrity, and availability impact, successful exploitation could allow local privilege escalation, kernel memory disclosure, system compromise, or a crash.

Why it matters to the business

The main business risk is that an attacker who already has a foothold on a Linux system, such as a compromised application account, shell user, container escape opportunity, or low-privileged service account, may be able to escalate to root or disrupt the host. This can turn a limited compromise into full system control, enabling data theft, tampering, persistence, lateral movement, or outages. The vulnerability is not listed in CISA KEV, is not currently associated with ransomware use, has low EPSS, and has no known public exploit maturity in the supplied data; however, it affects the Linux kernel, which is widely deployed and often embedded in downstream distributions, so patching should still be prioritized for multi-user servers, container hosts, CI/CD runners, bastion systems, and internet-facing workloads where local code execution is a realistic post-compromise step.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected Linux system with low privileges. They then create io_uring activity involving provided buffers and force request handling through paths such as io-wq to widen the timing window between buffer acquisition and recycling. During that window, the attacker races changes to the buffer list state so that the kernel code later performs legacy buffer recycling against a buffer list that has been removed, changed, or upgraded to a ring-provided type. If the race is won reliably, the resulting invalid object handling or memory corruption may be shaped into a kernel control-flow or data-only primitive. Depending on kernel build options, mitigations, and allocator behavior, exploitation may result in privilege escalation to root, credential manipulation, kernel memory disclosure, or a denial-of-service crash. Failed attempts may leave evidence only as kernel warnings, oopses, panics, or abnormal crashes of processes using io_uring.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the fix for the io_uring kbuf recycling validation issue. No exact fixed versions were supplied, so remediation should be based on vendor advisories for the deployed distribution and kernel stream. Where rapid patching is not immediately possible, reduce exposure by restricting unprivileged io_uring use where supported, limiting local shell access, tightening container isolation, reducing the number of untrusted workloads on shared hosts, and prioritizing reboot into the patched kernel after installation. Because kernel updates are only effective after the running kernel is replaced, ensure systems are actually rebooted or live-patched according to vendor guidance.

How to confirm the fix worked

Confirm the running kernel version, not just the installed package version, is updated to a vendor build containing the fix. Validate with commands such as `uname -r`, distribution package metadata, and vendor advisory references for the relevant kernel branch. If the environment uses live patching, confirm the live patch is active and covers this specific io_uring change. Review whether unprivileged io_uring is enabled or restricted according to distribution controls. For exposure validation, inventory Linux systems that permit local user execution, run containers, host CI/CD jobs, or provide shared compute, and compare their running kernels against vendor-fixed builds. For mitigation validation, test that unprivileged users cannot use io_uring if that control was intentionally disabled or restricted.

Typical attack path

1. Gain low-privileged local code execution on an affected Linux host.
2. Confirm that io_uring is available to unprivileged users and that the running kernel contains the vulnerable kbuf recycling logic.
3. Create io_uring workloads using provided buffers and operations likely to be handled through asynchronous worker paths.
4. Race buffer-list state changes so a legacy buffer recycle occurs after the list has been converted, removed, or otherwise no longer matches the expected type.
5. Trigger invalid kernel memory handling, memory corruption, or a kernel crash.
6. If exploitation is stable, convert the kernel memory corruption primitive into root-level privileges or use it to disable security controls, access protected data, or maintain persistence.

How to detect it

There is no reliable network-level signature because exploitation requires local code execution and abuses kernel behavior. Detection should focus on host telemetry and post-exploitation indicators. Review kernel logs from `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, and crash dump systems for io_uring-related warnings, kernel oopses, BUG messages, allocator corruption, KASAN reports, general protection faults, NULL pointer dereferences, use-after-free reports, or unexpected panics. Correlate these events with local processes making heavy io_uring use, unexpected execution from temporary directories, newly spawned root shells, suspicious setuid file creation, credential changes, service tampering, or security control disablement. On servers with auditd or EDR, look for low-privileged processes that abruptly transition to root-level actions without normal authentication, especially near kernel fault events. Because failed exploitation may only look like instability, repeated crashes involving io_uring or kernel buffer management on an unpatched host should be investigated as possible exploitation attempts.

• io_uring
• kbuf
• provided buffer
• buffer_list
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG
• Oops:
• KASAN: use-after-free
• KASAN: slab-out-of-bounds
• UBSAN:
• slab corruption
• kernel panic
• io-wq
• /var/log/kern.log
• /var/log/messages
• dmesg

What your security team should do

• Prioritize patching and rebooting affected multi-user Linux servers, container hosts, CI/CD runners, developer workstations, bastion hosts, and systems exposed to untrusted local workloads.
• Track vendor advisories for the deployed Linux distributions because exact fixed package versions were not supplied in the input.
• Inventory running kernel versions across the fleet and identify systems that are installed-but-not-rebooted after kernel updates.
• Where immediate patching is delayed, restrict unprivileged io_uring use if supported and operationally acceptable.
• Increase monitoring for kernel oops, panic, BUG, KASAN, slab, use-after-free, and io_uring-related crash messages on unpatched systems.
• Treat suspicious local privilege escalation activity on vulnerable hosts as high severity, even though EPSS is currently low and the vulnerability is not listed in KEV.
• Harden local attack paths by minimizing shell access, isolating containers, disabling unnecessary user accounts, and applying least privilege to service accounts.