Cloudanix VulnDB

CVE-2026-98858

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in the Linux kernel's fast input-output system can let a local attacker crash the machine or gain elevated privileges by racing request completion against background cleanup.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in io_uring SQPOLL path: sqpoll thread pops and completes requests immediately after mpscq_push while io_req_normal_work_add still dereferences the ctx and tctx; io_ring_exit_work frees the ctx without an RCU grace period, allowing slab access after free.

Why it matters to the business

Kernel memory corruption on Linux systems that use io_uring with SQPOLL can produce crashes, denial of service, or local privilege escalation; high-IO workloads and recent kernels are most exposed.

How an attack unfolds

Attacker issues rapid io_uring requests under SQPOLL so that the final request completion triggers io_ring_exit_work; the freed ctx is then read or written by io_req_normal_work_add or queue_work_on before RCU protection is in place.

How to fix it

Apply the kernel commit that adds RCU read lock around io_req_normal_work_add for SQPOLL rings and ensures io_ring_exit_work waits for a grace period before freeing the ctx; rebuild and reboot with the patched kernel.

How to confirm the fix worked

Confirm the RCU read-lock and grace-period changes are present in the running kernel source; run reproducers that previously triggered KASAN reports and verify they no longer produce slab-use-after-free warnings.

Typical attack path

  1. Create io_uring ring with SQPOLL enabled
  2. Submit enough requests to reach the exit condition
  3. Force ring teardown while work items are still pending
  4. Trigger slab reuse to convert the use-after-free into memory corruption or control-flow hijack

How to detect it

Search kernel logs and KASAN reports for slab-use-after-free involving io_req_normal_work_add, queue_work_on, io_ring_exit_work, or SQPOLL context; correlate with processes that create io_uring rings.

  • BUG: KASAN: slab-use-after-free in io_req_normal_work_add
  • BUG: KASAN: slab-use-after-free in queue_work_on
  • io_ring_exit_work
  • SQPOLL

What your security team should do

  • Patch kernels within the next maintenance window on all systems that expose io_uring to untrusted workloads
  • Disable SQPOLL where not required until patches are deployed
  • Add kernel panic and KASAN monitoring for io_uring symbols
  • Review container or VM images for outdated kernels

The record

In the Linux kernel, the following vulnerability has been resolved: io_uring: fix task_work add use-after-free with SQPOLL For SQPOLL, the sqpoll thread runs task_work off its own list and doesn't need to be told about it, so it can pop and complete a request as soon as mpscq_push() has published it. If that was the last request holding the ring alive, io_ring_exit_work() then frees the ctx, stops the thread, and with it the tctx, while io_req_normal_work_add() is still looking at both after the push: BUG: KASAN: slab-use-after-free in io_req_normal_work_add+0x439/0x510 Read of size 4 at addr ff11000000ca0000 by task repro/55 (...) BUG: KASAN: slab-use-after-free in queue_work_on+0x25/0x70 Write of size 8 at addr ff11000000c3bd00 by task repro/55 Hold an RCU read lock across the add, like io_req_local_work_add() already does, and have io_ring_exit_work() wait for a grace period for SQPOLL rings as well before freeing the ctx.

Affected packages

Ecosystem Package Introduced Fixed