CVE-2025-71070
lowCVSS v3 Base Score
3.3
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
EPSS Score
0.0%
Exploitation probability in 30 days
Top 93% most likely to be exploited
Attack Characteristics
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Confidentiality
None
Integrity
None
Availability
Low
Vulnerability Report
Generated by CyberWatcher
Description
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.
CWE
CWE-911Affected Products
Red Hat Enterprise Linux 10Red Hat Enterprise Linux 6Red Hat Enterprise Linux 7Red Hat Enterprise Linux 8Red Hat Enterprise Linux 9