Cloudanix VulnDB

CVE-2025-68823

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Jan 13, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel can make the computer freeze when handling certain disk devices, forcing a restart to get it working again.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

A deadlock occurs in the ublk driver when a process opens the block device to read the partition table: bdev_open acquires disk->open_mutex, a read I/O triggers bio end_io callbacks in __ublk_complete_rq that may defer fput and blkdev_release to the same task context via task work, causing a second attempt to acquire the mutex.

Why it matters to the business

Local users on affected Linux systems can trigger kernel deadlocks leading to system hangs or unresponsiveness on ublk devices, disrupting disk operations and requiring reboots; widespread use of the kernel in servers and appliances amplifies operational downtime risk.

How an attack unfolds

A local process such as udev opens the ublk block device and issues a read for the partition table; the I/O completion path invokes bi_end_io callbacks that schedule blkdev_release on the current task, resulting in recursive mutex acquisition and deadlock without any special privileges beyond local access.

How to fix it

Update the Linux kernel to a version containing commit 64c0b7e2293757e8320f13434cd809f1c9257a62. For the listed packages apply the exact fixed versions: github.com/mattermost/mattermost/server/v8 to 8.0.0-20250905150616-ba86dfc5876b and org/pub/scm/linux/kernel/git/stable/linux.git to 64c0b7e2293757e8320f13434cd809f1c9257a62.

How to confirm the fix worked

Confirm the running kernel contains the referenced fix commit via git log or package version checks; reproduce the partition table read scenario on a ublk device to verify absence of deadlock.

Typical attack path

  1. Local process opens ublk block device via bdev_open acquiring open_mutex
  2. Issues read I/O to retrieve partition table
  3. Completion handler runs bio callbacks and defers fput to task work
  4. blkdev_release attempts to reacquire the held mutex causing deadlock

How to detect it

Inspect kernel logs for deadlock warnings, hung task reports, or stack traces referencing ublk_complete_rq, blkdev_release, or open_mutex; correlate with processes performing partition table reads on block devices.

What your security team should do

  • Prioritize kernel upgrades to the listed fixed commits on all systems using ublk
  • Restrict untrusted local access to block devices until patched
  • Monitor kernel logs for hung tasks involving ublk or open_mutex

The record

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]

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.0.0 6.6.124

Related vulnerabilities