LiveActive security incident?Get immediate response
CVE Record

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]

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
7

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux71f28f3136aff5890cd56de78abc673f8393cad9, 71f28f3136aff5890cd56de78abc673f8393cad9, 71f28f3136aff5890cd56de78abc673f8393cad9, 71f28f3136aff5890cd56de78abc673f8393cad9, 71f28f3136aff5890cd56de78abc673f8393cad9unaffected
LinuxLinux6.0, 0, 6.1.175, 6.6.124, 6.12.70, 6.18.3, 6.19affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.