CVE-2026-53124

What it actually does

This is a Linux kernel denial-of-service flaw in the ublk userspace block device subsystem. During ublk device recovery, a per-I/O cancellation flag can remain set after some, but not all, queued I/O fetch commands have been submitted. If the ublk server exits or crashes before fetching the remaining I/O requests, cancellation for the already-fetched subset may never complete because the kernel incorrectly suppresses completion of outstanding io_uring commands. The practical effect is stuck I/O, incomplete cancellation, hung ublk queues, and potentially blocked processes waiting on affected block devices.

Why it matters to the business

Systems using ublk-backed block devices may experience storage stalls, application hangs, degraded service availability, or node-level operational disruption if a ublk server crashes or is intentionally terminated during recovery. The risk is most relevant to environments that rely on userspace block devices for storage virtualization, custom block services, testing infrastructure, or containerized storage components. Public exploitation is not currently indicated, EPSS is very low, and it is not in the Known Exploited Vulnerabilities catalog, but kernel-level availability issues can still have high operational impact on affected hosts.

How an attack unfolds

An attacker needs a way to influence or control a system using the Linux ublk subsystem, typically through local access, control over a ublk userspace server, or the ability to cause that server to crash or terminate at a precise point during device recovery. The attacker triggers recovery of ublk devices and allows only a nonempty subset of queued I/O fetch commands to be submitted. The attacker then causes the ublk server to exit before all I/Os for the queue are fetched. Because the affected kernel resets cancellation state only after the full queue has been fetched, the already-fetched I/Os can retain a stale canceled flag. Subsequent cancellation attempts may fail to complete those outstanding commands, leaving I/O permanently stuck. This can result in hung processes, blocked storage operations, and denial of service for workloads depending on the affected ublk device.

How to fix it

Upgrade to a Linux kernel release or distribution kernel package that includes the ublk fix which resets the per-I/O canceled flag immediately when each I/O is fetched. Because no exact fixed package versions were provided, follow the security advisory from the relevant Linux distribution or kernel supplier and update all hosts that enable or use ublk. Where immediate patching is not possible, reduce exposure by disabling or avoiding ublk-backed devices if they are not required, restricting who can run or manage ublk userspace servers, supervising ublk server processes to restart cleanly, and isolating workloads that depend on experimental or userspace-managed block devices.

How to confirm the fix worked

Confirm that the running kernel includes the vendor fix for the ublk per-I/O cancellation handling issue. Validate by checking the installed kernel package against the distribution advisory, confirming the host has rebooted into the patched kernel, and verifying that ublk workloads can recover from userspace server termination without leaving persistent hung I/O. Operational validation should include reviewing dmesg or journal logs for ublk-related hangs after patching and running controlled recovery or failover tests in non-production environments where ublk is used.

Typical attack path

1. Obtain local execution or operational control over a component that can create, manage, or disrupt ublk devices or their userspace server.
2. Start or wait for ublk device recovery while there are multiple queued I/O operations.
3. Allow only some queued I/O fetch commands to be issued successfully.
4. Terminate, crash, or otherwise kill the ublk server before all I/O requests in the queue are fetched.
5. Cause the kernel to attempt cancellation of the outstanding fetch commands.
6. Exploit the stale per-I/O canceled flag state so some outstanding commands are never completed.
7. Leave dependent applications or services blocked on storage I/O, producing a denial-of-service condition.

How to detect it

Look for evidence of ublk device recovery followed by ublk userspace server termination, persistent hung tasks, blocked I/O, or processes stuck in uninterruptible sleep while accessing ublk-backed devices. Useful sources include kernel logs from dmesg, journalctl -k, system logs, process supervision logs for ublk servers, service manager logs, container runtime logs if the ublk server runs in a container, and storage/application logs showing I/O timeouts. Search for repeated ublk messages near process exits, SIGKILL/SIGSEGV events, OOM kills, or service restarts. Also review host metrics for sudden increases in iowait, blocked tasks, and application timeouts correlated with ublk server failure. There are no reliable remote network indicators for this issue because exploitation is tied to local kernel and userspace block-device behavior.

• ublk
• /dev/ublkc
• /dev/ublkb
• ublk server
• ublk_cancel_cmd
• io_uring_cmd_done
• blocked for more than
• INFO: task
• hung_task
• uninterruptible sleep
• D state
• I/O timeout
• io_uring
• Out of memory: Killed process
• segfault

What your security team should do

• Inventory Linux systems that load or use the ublk subsystem, including hosts with /dev/ublkc* or /dev/ublkb* devices and workloads using userspace block services.
• Prioritize kernel updates on systems where ublk-backed storage supports production workloads or shared infrastructure.
• Restrict local privileges required to create, control, or terminate ublk devices and their userspace servers.
• Add monitoring for ublk server crashes, repeated recovery events, hung tasks, and prolonged I/O wait on ublk-backed devices.
• If ublk is not required, disable its use or prevent the module from being loaded according to distribution-supported controls.
• After patching, reboot into the fixed kernel and verify the running kernel version, not only the installed package version.
• Treat unexplained ublk-related hangs or blocked I/O as potential security-relevant availability incidents, even though known exploitation has not been reported.