Linux Kernel CVE-2025-71070

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.

The Linux kernel's ublk driver is affected on versions that include commit e63d2228ef83 ('ublk: simplify aborting ublk request') up to the fix, specifically for devices using the UBLK_F_USER_COPY data-copy mode (the zero-copy and auto-buf-reg modes were already remediated by commit c5c5eb24ed61). Fixed stable commits are published at https://git.kernel.org/stable/c/13456b4f1033d911f8bf3a0a1195656f293ba0f6 and https://git.kernel.org/stable/c/daa24603d9f0808929514ee62ced30052ca7221c. Ubuntu tracks this in USN-8177-1 (https://ubuntu.com/security/notices/USN-8177-1), and VulDB entry 340635 (https://vuldb.com/vuln/340635) provides additional cross-referencing. Exact affected version ranges depend on which stable trees backported the regressing commit; no CPE strings were provided in the input, so precise version boundaries should be confirmed against each distribution's kernel changelog.