CVE-2025-68823: ublk: fix deadlock when reading partition table
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 bdevopen()), a deadlock[1] can occur:
1. bdevopen() grabs disk->openmutex 2. The process issues read I/O to ublk backend to read partition table 3. In ublkcompleterq(), blkupdaterequest() or blkmqendrequest() runs bio->biendio() callbacks 4. 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) 5. This eventually calls blkdevrelease() from the same context 6. blkdevrelease() tries to grab disk->openmutex again 7. Deadlock: same task waiting for a mutex it already holds
The fix is to run blkupdaterequest() and blkmqendrequest() with bottom halves disabled. This forces blkdevrelease() 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]
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2025-68823?
CVE-2025-68823 is classified with a high severity due to the potential for a deadlock affecting system stability.
How do I fix CVE-2025-68823?
To fix CVE-2025-68823, update to the latest stable version of the Linux kernel where the deadlock issue is resolved.
What systems are affected by CVE-2025-68823?
CVE-2025-68823 affects systems running the vulnerable versions of the Linux kernel that utilize ublk block devices.
What causes the deadlock in CVE-2025-68823?
The deadlock in CVE-2025-68823 occurs when a process, such as udev, attempts to open a ublk block device to read the partition table.
Is there a workaround for CVE-2025-68823?
Implementing a temporary workaround for CVE-2025-68823 is not recommended; the best approach is to apply the kernel update.