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 bdev_open()), a deadlock[1] can occur:
1. bdev_open() grabs disk->open_mutex
2. The process issues read I/O to ublk backend to read partition table
3. In __ublk_complete_rq(), blk_update_request() or blk_mq_end_request()
runs bio->bi_end_io() 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 blkdev_release() from the same context
6. blkdev_release() tries to grab disk->open_mutex again
7. 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]
Security readout for executives and security teams
Plain-English summary
CVE-2025-68823 is a Linux kernel reliability flaw in ublk block devices. A normal partition-table read can trigger a deadlock, leaving related storage operations stuck. The source describes a kernel fix, but gives no CVSS score or evidence of exploitation.
Executive priority
Treat this as a reliability and availability patch, not an emergency compromise indicator. Prioritize systems where storage availability matters and ublk is used. Lack of severity scoring and exploit evidence lowers urgency, but kernel deadlocks can still create operational outages.
Technical view
The ublk completion path can call request-ending functions while the opener still holds disk->open_mutex. If fput() causes blkdev_release() in the same task context, the task attempts to reacquire the same mutex and deadlocks. The kernel fix disables bottom halves around blk_update_request() and blk_mq_end_request() so release work runs elsewhere.
Likely exposure
Exposure is most likely on Linux systems running affected kernels with ublk block devices in use. The described trigger involves processes such as udev opening a ublk block device to read a partition table. Distribution backport status is not provided in the source bundle.
Exploitation context
The source bundle does not report active exploitation, and KEV status is false. The issue appears to be a denial-of-service style deadlock rather than data theft or privilege escalation, based on the provided description only.
Researcher notes
The record names stable kernel commits but provides no CVSS, CWE, PoC, or distro mapping. Analysis should focus on ublk usage, affected kernel lineage, and confirmation that the bottom-half disabling fix is present in the deployed kernel source or vendor build.
Mitigation direction
Upgrade to a kernel build containing the referenced stable ublk fixes.
Check Linux distribution advisories for backported fixes and supported package versions.
Prioritize hosts that use ublk block devices or automated partition scanning.
Monitor affected hosts for storage hangs until patched.
Avoid unnecessary ublk deployments where vendor guidance supports doing so.
Validation and detection
Inventory Linux kernel versions across systems using ublk.
Confirm whether ublk block devices are present or operationally required.
Verify the running kernel includes the relevant stable fix commit or vendor backport.
Review logs and monitoring for recurring block-device open or partition-scan hangs.
Test patched kernels in staging before production rollout.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-68823 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 13, 2026, 15:29 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.