CVE-2021-47292

What it actually does

Race condition during parallel io_uring_enter calls allows multiple allocations of a hash_map structure without synchronization, leaving one allocation unreferenced and causing a memory leak.

Why it matters to the business

Repeated triggering can gradually exhaust kernel memory on systems using io_uring, leading to degraded performance or denial of service over time; low EPSS and no known exploitation reduce immediate risk despite the 882-day publication age.

How an attack unfolds

An attacker invokes io_uring_enter concurrently from multiple threads or processes; each path reaches io_uring_alloc_task_context and io_init_wq_offload, both performing an unprotected kzalloc for the hash_map, so one allocation is lost while the other is stored, repeating the leak on every concurrent entry.

How to fix it

Apply the fix that adds uring_lock protection around hash_map; for affected okhttp packages update to commit 3edf17ca8a5048912d19e84d0fc2a7941a97c07d.

How to confirm the fix worked

Confirm the uring_lock is present around hash_map assignment in io_init_wq_offload; run concurrent io_uring_enter fuzz tests and verify no memory leaks are reported by kmemleak or similar tools.

Typical attack path

1. Identify a process or service that uses io_uring
2. Spawn multiple threads that simultaneously call io_uring_enter
3. Trigger the race in io_uring_add_tctx_node and io_uring_alloc_task_context
4. Repeat to accumulate unreferenced hash_map allocations
5. Monitor for memory pressure or OOM conditions

How to detect it

Review kernel memory leak detectors and audit logs for repeated io_uring_enter entries from the same task; look for allocation patterns matching the backtrace involving io_init_wq_offload.

What your security team should do

• Prioritize patching systems that expose io_uring to untrusted workloads
• Monitor memory usage trends on io_uring-enabled hosts
• Disable io_uring via kernel parameters where the interface is unnecessary