CVE-2024-50060

What it actually does

Missing reschedule check during io_uring overflow list flush allows a large number of entries to be processed while holding locks for an extended period, potentially triggering soft lockups or DoS.

Why it matters to the business

Attackers with local access can trigger prolonged kernel lock contention leading to system unresponsiveness, degraded performance, or crashes on Linux systems using io_uring, increasing downtime risk especially in high-throughput environments.

How an attack unfolds

An attacker crafts a workload that intentionally generates a large volume of overflow entries in io_uring; when the kernel attempts to flush the list it holds locks without yielding, causing extended execution time that can starve other tasks or trigger watchdog timeouts. Listed threat actors in 2024 espionage and financially motivated campaigns have targeted similar Linux kernel issues for privilege escalation or denial of service.

How to fix it

Update the Linux kernel to a version containing commit a2493904e95ce94bbec819d8f7f03b99976eb25c or later; for Rocky Linux 8 openssl packages apply 1:1.1.1k-6.el8_5 or equivalent distribution backports. Reboot after kernel updates.

How to confirm the fix worked

Confirm the running kernel contains the reschedule check in the io_uring overflow flush path; review dmesg or kernel logs for absence of soft lockup warnings during high io_uring load tests; verify package versions match the listed fixed releases.

Typical attack path

1. Obtain local code execution on a Linux system
2. Use io_uring interfaces to deliberately overflow the completion queue with many entries
3. Trigger the overflow flush path while holding relevant locks
4. Prevent rescheduling long enough to cause soft lockup or system impact

How to detect it

Review kernel logs for soft lockup or hung task messages involving io_uring; inspect audit or syscall logs for unusual io_uring setup and completion patterns; correlate with process activity generating high volumes of completion events.

What your security team should do

• Prioritize kernel upgrades on all systems exposing io_uring to untrusted local workloads
• Monitor EPSS and KEV status for changes given the 721 days since publication
• Restrict unprivileged io_uring access via seccomp or LSM policies where possible
• Test the fix under synthetic overflow conditions before broad deployment