Overview
About vulnerability
In the Linux kernel, the following vulnerability has been resolved: ublk: fix deadlock when reading partition table When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdev_open()), a deadlock[1] can occur:
- bdev_open() grabs disk->open_mutex
- The process issues read I/O to ublk backend to read partition table
- In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request() runs bio->bi_end_io() callbacks
- If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task’s task work (see fput() implementation)
- This eventually calls blkdev_release() from the same context
- blkdev_release() tries to grab disk->open_mutex again
- Deadlock: same task waiting for a mutex it already holds The fix is to run blk_update_request() and blk_mq_end_request() with bottom halves disabled. This forces blkdev_release() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock. [axboe: rewrite comment in ublk] A flaw was found in the Linux kernel’s ublk driver. A local attacker, by opening a ublk block device to read its partition table, could trigger a deadlock. This vulnerability leads to a Denial of Service (DoS) as the same task waits for a mutex it already holds, preventing further operations.
Details
KernelCare state
Live-patch status from KernelCare for each operating system.
| Operating system | Status | Covered kernels |
|---|---|---|
| Debian 12 | Planned | — |
| Debian 13 | Planned | — |
| Ubuntu 24.04 | Released |
43 kernels
|
| Ubuntu 24.04 AWS | Planned | — |