CVE-2023-53461

What it actually does

io_ring_exit_work in the Linux kernel io_uring subsystem waits for request completions in TASK_UNINTERRUPTIBLE state, allowing the hung task detector to falsely trigger when the owning task is stopped and task_work is required for completion, potentially leading to kernel panic if panic-on-hung-task is enabled.

Why it matters to the business

Systems running affected kernels may experience unexpected panics and downtime during io_uring ring exits under load or when processes are paused, increasing operational risk in environments with strict availability requirements; the issue has been public for over a year with low exploitation probability.

How an attack unfolds

An attacker with local access triggers io_uring ring creation and exit while arranging for the owning task to be stopped via signal; the uninterruptible wait in io_ring_exit_work then causes the hung task checker to fire, leading to denial of service if panic-on-hung-task is active. No named threat actors are associated with this specific flaw.

How to fix it

Upgrade to a kernel containing commit 28e649dc9947e6525c95e32aa9a8e147925e3f56 or apply the equivalent fix that changes the wait state to TASK_INTERRUPTIBLE in io_ring_exit_work; for packaged distributions update golang-golang-x-text to version 0.3.3-1 where applicable.

How to confirm the fix worked

Confirm the presence of commit 28e649dc9947e6525c95e32aa9a8e147925e3f56 in the running kernel source or verify package versions match the fixed releases; test ring exit behavior under SIGSTOP conditions without observing hung task warnings.

Typical attack path

1. Obtain local execution on a system using io_uring
2. Create an io_uring ring and issue requests
3. Stop the owning task (e.g., via SIGSTOP)
4. Exit the ring to invoke io_ring_exit_work
5. Trigger hung task detection and potential kernel panic

How to detect it

Search kernel logs for hung task warnings referencing io_ring_exit_work or io_uring during process exit; inspect dmesg or syslog for TASK_UNINTERRUPTIBLE waits coinciding with ring teardown and SIGSTOP signals.

What your security team should do

• Prioritize kernel upgrades on systems with panic-on-hung-task enabled
• Monitor for io_uring usage in container and server workloads
• Review and disable panic-on-hung-task where not strictly required until patched
• Track EPSS and KEV updates for any change in observed exploitation