CVE-2025-71070 in Linux
Summary
by MITRE • 01/13/2026
In the Linux kernel, the following vulnerability has been resolved:
ublk: clean up user copy references on ublk server exit
If a ublk server process releases a ublk char device file, any requests dispatched to the ublk server but not yet completed will retain a ref value of UBLK_REFCOUNT_INIT. Before commit e63d2228ef83 ("ublk: simplify aborting ublk request"), __ublk_fail_req() would decrement the reference count before completing the failed request. However, that commit optimized __ublk_fail_req() to call __ublk_complete_rq() directly without decrementing the request reference count. The leaked reference count incorrectly allows user copy and zero copy operations on the completed ublk request. It also triggers the WARN_ON_ONCE(refcount_read(&io->ref)) warnings in ublk_queue_reinit() and ublk_deinit_queue(). Commit c5c5eb24ed61 ("ublk: avoid ublk_io_release() called after ublk char dev is closed") already fixed the issue for ublk devices using UBLK_F_SUPPORT_ZERO_COPY or UBLK_F_AUTO_BUF_REG. However, the reference count leak also affects UBLK_F_USER_COPY, the other reference-counted data copy mode. Fix the condition in ublk_check_and_reset_active_ref() to include all reference-counted data copy modes. This ensures that any ublk requests still owned by the ublk server when it exits have their reference counts reset to 0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/21/2026
The vulnerability described in CVE-2025-71070 affects the Linux kernel's ublk subsystem, which provides a framework for implementing user-space block devices. This issue represents a reference count management flaw that can lead to resource leakage and potential security implications within the kernel's device handling mechanisms. The ublk subsystem operates by creating character devices that allow user-space applications to implement block device functionality, with the kernel managing the communication between the user-space server and the kernel's block layer.
The core technical flaw stems from improper cleanup of reference counts when a ublk server process exits while still managing active requests. Specifically, when a ublk server releases its character device file, requests that were dispatched to the server but not yet completed retain their initial reference count value of UBLK_REFCOUNT_INIT. This occurs because a previous optimization in commit e63d2228ef83 modified the __ublk_fail_req() function to call __ublk_complete_rq() directly without decrementing the reference count, creating a scenario where reference counts become permanently inflated. The problem manifests when the ublk server terminates while holding references to requests that should have been properly cleaned up, leading to incorrect resource state management.
The operational impact of this vulnerability extends beyond simple resource leakage to potentially compromise system stability and security. The leaked reference counts incorrectly permit user copy and zero copy operations on completed ublk requests, which violates expected resource management semantics and can lead to unpredictable behavior in the block device subsystem. Additionally, the issue triggers WARN_ON_ONCE(refcount_read(&io->ref)) warnings in critical kernel functions ublk_queue_reinit() and ublk_deinit_queue(), indicating that the kernel's internal state validation has detected inconsistent reference counting. This can result in system instability, particularly during device reinitialization or shutdown sequences, and may provide an avenue for denial of service attacks against kernel subsystems.
The fix implemented in commit c5c5eb24ed61 addresses the issue by modifying the ublk_check_and_reset_active_ref() function to properly handle all reference-counted data copy modes rather than just the previously covered UBLK_F_SUPPORT_ZERO_COPY and UBLK_F_AUTO_BUF_REG flags. This comprehensive approach ensures that when a ublk server exits, any requests still owned by the server have their reference counts reset to zero regardless of the specific copy mode being used. This change aligns with the principle of proper resource cleanup and follows established kernel development practices for reference counting management. The solution demonstrates adherence to security best practices by ensuring that all resource management paths properly account for cleanup operations, preventing potential exploitation through resource exhaustion or state corruption attacks that could leverage the improper reference count handling within the ublk subsystem.
This vulnerability relates to CWE-404, which covers improper resource management, and aligns with ATT&CK techniques involving privilege escalation through kernel vulnerabilities. The issue demonstrates how seemingly minor optimizations in kernel code can introduce security flaws that affect resource management and system stability, emphasizing the critical importance of thorough testing and validation of kernel modifications, particularly those involving reference counting and resource cleanup operations.