CVE-2026-53321: Linux kernel · io_uring/napi: cap busy_poll_to 10 msec
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in df8599ee18c0e5fe343ffe0b4c379636b8bb839a : update Linux kernel when convenient.
Data as of 26 Oct 2026, 13:47 UTC
Rated by Threat Radar · No CVSS score from NVD or the CNA
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 5% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in df8599ee18c0e5fe343ffe0b4c379636b8bb839a, cb3af525f8dfb8930f0c123e5755fa967a12d5c1, 42785efe813e5a7d815f3b6be126e1bc0d12d2b6 +1
Exploitation evidence
Disclosed: evidence found.
CVE published 26 Jun 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade Linux kernel to df8599ee18c0e5fe343ffe0b4c379636b8bb839a, cb3af525f8dfb8930f0c123e5755fa967a12d5c1, 42785efe813e5a7d815f3b6be126e1bc0d12d2b6 or 39767f944a8c9e696566c37ad5b20131406c4b8d.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: io_uring/napi: cap busy_poll_to 10 msec Currently there's no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there's no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that's already way above any kind of sane value that will reap any benefits, yet low enough that it's nowhere near being able to trigger preemption complaints.
References
- git.kernel.org/stable/c/42785efe813e5a7d815f3b6be126e1bc0d12d2b6 (opens in a new tab)
- git.kernel.org/stable/c/39767f944a8c9e696566c37ad5b20131406c4b8d (opens in a new tab)
- git.kernel.org/stable/c/cb3af525f8dfb8930f0c123e5755fa967a12d5c1 (opens in a new tab)
- git.kernel.org/stable/c/df8599ee18c0e5fe343ffe0b4c379636b8bb839a (opens in a new tab)