CVE-2026-53321

What it actually does

This Linux kernel flaw is a denial-of-service condition in the io_uring NAPI busy-polling path. When io_uring is configured to use NAPI busy polling and no network events are found, the kernel could remain in the polling loop without a practical upper time bound and without conditional rescheduling. That can trigger kernel hung-task or preemption watchdog complaints, waste CPU, delay scheduling of other work, and degrade system responsiveness. The upstream fix caps the NAPI busy-poll duration to 10 milliseconds, preventing excessive time spent in the loop.

Why it matters to the business

Successful exploitation can cause affected Linux systems to experience CPU starvation, degraded application performance, noisy kernel watchdog alerts, and possible service disruption. The risk is primarily operational availability rather than data theft or privilege escalation. The CVE is not currently listed in CISA KEV, is not marked as ransomware-used, has very low EPSS, and has no reported public exploit maturity, so broad exploitation pressure appears low; however, internet-facing or multi-tenant Linux workloads that permit untrusted local code execution should still prioritize patching because kernel-level denial-of-service issues can affect many services on the same host.

How an attack unfolds

An attacker first needs the ability to run code on an affected Linux system or otherwise trigger a workload path that can create and drive io_uring operations using NAPI busy polling. The attacker repeatedly submits io_uring activity in a way that enters the NAPI busy-poll path while producing no events to consume. Because the vulnerable kernel does not sufficiently cap how long the loop can poll before yielding, the task can spend excessive time in kernel space. Repetition or concurrency can amplify the effect, leading to CPU consumption, scheduler delays, and kernel watchdog messages such as hung-task or soft-lockup complaints. This is not a typical remote unauthenticated code-execution issue; it is most relevant where untrusted users, containers, sandboxed workloads, or application plugins can exercise io_uring on vulnerable kernels.

How to fix it

Upgrade the Linux kernel to a version that includes the upstream fix for the io_uring NAPI busy-poll cap, specifically the patch that limits busy_poll_to behavior to 10 milliseconds. Because no product-specific fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory rather than relying only on upstream version numbers. If immediate patching is not possible, reduce exposure by disabling or restricting unprivileged io_uring where supported, using seccomp or container runtime policy to block io_uring-related syscalls for untrusted workloads, limiting local shell access, and reviewing whether NAPI busy-poll features are needed. Potential hardening controls include kernel.io_uring_disabled where available, container seccomp profiles that deny io_uring_setup/io_uring_enter/io_uring_register for untrusted workloads, and disabling unnecessary network busy-poll tuning. Mitigations should be tested carefully because io_uring is used by some high-performance applications.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor fix for this CVE or the upstream change titled "io_uring/napi: cap busy_poll_to 10 msec." Validate using the distribution package changelog, security advisory, or kernel source tree rather than the reported kernel version alone, because many vendors backport fixes. On hosts, compare `uname -r` and package metadata against the vendor’s fixed release. Where source validation is possible, inspect the io_uring NAPI code path and confirm that the busy-poll timeout is capped to 10 milliseconds. After patching or mitigation, run representative io_uring and network workloads and monitor for absence of new hung-task, soft-lockup, or io_uring/NAPI-related kernel warnings. For mitigation validation, verify that untrusted workloads cannot invoke io_uring syscalls if those controls were applied.

Typical attack path

1. Gain the ability to execute code on a vulnerable Linux host, container host, or workload environment where io_uring is available.
2. Create one or more io_uring instances and configure or trigger NAPI busy-poll behavior.
3. Submit operations that cause the kernel to enter the NAPI polling path while no completions or network events are available.
4. Keep the polling path active repeatedly or concurrently so the vulnerable loop spends excessive time without rescheduling.
5. Cause CPU starvation, scheduling latency, kernel watchdog warnings, and potential application or host-level service degradation.

How to detect it

Look for evidence of availability abuse or repeated triggering of the vulnerable path in kernel and system logs. Relevant sources include `dmesg`, journald kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, audit logs for io_uring syscalls if syscall auditing is enabled, EDR process telemetry, and container runtime logs. Focus on time periods with unexplained CPU saturation, scheduler latency, application timeouts, or host health alerts. Search for kernel watchdog messages such as hung tasks, soft lockups, RCU stalls, and preemption complaints that mention io_uring, NAPI, busy polling, or processes with unusual local workload behavior. If auditd or eBPF telemetry captures syscalls, look for abnormal volumes of `io_uring_setup`, `io_uring_enter`, or `io_uring_register` from untrusted users, containers, or unexpected binaries. There are no unique network indicators because exploitation is local/workload-driven rather than a distinctive remote packet pattern.

• io_uring_setup
• io_uring_enter
• io_uring_register
• io_uring
• napi
• busy_poll
• busy poll
• hung_task
• INFO: task
• blocked for more than
• task blocked for more than
• soft lockup
• BUG: soft lockup
• watchdog: BUG: soft lockup
• rcu_sched detected stalls
• RCU stall
• preempt
• kernel: INFO: task
• kernel: watchdog
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux systems that run kernels with io_uring enabled, especially container hosts, shared compute, CI/CD runners, developer workstations, and systems that execute untrusted code.
• Prioritize patching multi-tenant and untrusted-code environments first, even though EPSS is low and there is no KEV listing.
• Apply vendor kernel updates that include the io_uring NAPI busy-poll cap; reboot systems where required so the fixed kernel is actually running.
• Where patching is delayed, restrict unprivileged io_uring through sysctl, seccomp, or container runtime policy for workloads that do not require it.
• Review kernel logs for hung-task, soft-lockup, RCU stall, or io_uring/NAPI-related warnings that began before patch deployment.
• Add monitoring for sudden increases in CPU usage combined with kernel watchdog messages on affected Linux systems.
• Test performance-sensitive applications after disabling or restricting io_uring, because some databases, proxies, runtimes, and storage/network applications may rely on it.