CVE-2025-37759 in Linux
Summary
by MITRE • 05/01/2025
In the Linux kernel, the following vulnerability has been resolved:
ublk: fix handling recovery & reissue in ublk_abort_queue()
Commit 8284066946e6 ("ublk: grab request reference when the request is handled by userspace") doesn't grab request reference in case of recovery reissue. Then the request can be requeued & re-dispatch & failed when canceling uring command.
If it is one zc request, the request can be freed before io_uring returns the zc buffer back, then cause kernel panic:
[ 126.773061] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 126.773657] #PF: supervisor read access in kernel mode
[ 126.774052] #PF: error_code(0x0000) - not-present page
[ 126.774455] PGD 0 P4D 0
[ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI
[ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 Not tainted 6.14.0_blk+ #182 PREEMPT(full)
[ 126.775676] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014
[ 126.776275] Workqueue: iou_exit io_ring_exit_work
[ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv]
Fixes it by always grabbing request reference for aborting the request.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 03/16/2026
The vulnerability CVE-2025-37759 affects the Linux kernel's ublk subsystem, specifically within the ublk_abort_queue() function. This issue stems from an incomplete implementation of request reference handling during recovery and reissue operations. The problem was introduced in commit 8284066946e6 which attempted to grab request references when requests are handled by userspace but failed to account for recovery reissue scenarios. This oversight creates a race condition where requests can be prematurely requeued and re-dispatched before proper cleanup occurs, leading to critical system instability.
The technical flaw manifests when a zc (zero-copy) request is processed through the io_uring subsystem. During cancellation of io_uring commands, the system attempts to handle request recovery and reissue without properly maintaining reference counts. When a zc request is cancelled, it may be freed before the io_uring subsystem has returned the zero-copy buffer, creating a dangling pointer scenario that results in kernel NULL pointer dereference. The crash occurs at the ublk_io_release function where the kernel attempts to access memory at address 0x00000000000000c8, triggering a kernel panic that terminates system operation.
This vulnerability represents a critical security and stability issue that can be exploited to cause denial of service through kernel panic conditions. The operational impact extends beyond simple system crashes as it affects the reliability of storage I/O operations in virtualized environments where ublk drivers are commonly used. The issue affects systems running kernel versions that include the problematic commit, particularly those utilizing io_uring with zero-copy operations and ublk storage drivers. The vulnerability aligns with CWE-476 which describes NULL pointer dereference conditions, and could potentially be leveraged by attackers to cause system instability or perform privilege escalation attacks depending on the execution context.
The fix implemented addresses this by ensuring that request references are always grabbed during the aborting process, regardless of whether the operation is a normal completion or a recovery reissue. This maintains proper reference counting and prevents premature freeing of request structures before all dependent operations complete. The mitigation strategy requires updating to a kernel version that includes the fix, which should be prioritized in production environments using ublk drivers or io_uring with zero-copy functionality. System administrators should also monitor for similar race conditions in other subsystems and ensure proper testing of storage driver updates before deployment to maintain system stability and prevent potential exploitation.