CVE-2025-39791
Fecha de publicación:
11/09/2025
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
dm: dm-crypt: Do not partially accept write BIOs with zoned targets<br />
<br />
Read and write operations issued to a dm-crypt target may be split<br />
according to the dm-crypt internal limits defined by the max_read_size<br />
and max_write_size module parameters (default is 128 KB). The intent is<br />
to improve processing time of large BIOs by splitting them into smaller<br />
operations that can be parallelized on different CPUs.<br />
<br />
For zoned dm-crypt targets, this BIO splitting is still done but without<br />
the parallel execution to ensure that the issuing order of write<br />
operations to the underlying devices remains sequential. However, the<br />
splitting itself causes other problems:<br />
<br />
1) Since dm-crypt relies on the block layer zone write plugging to<br />
handle zone append emulation using regular write operations, the<br />
reminder of a split write BIO will always be plugged into the target<br />
zone write plugged. Once the on-going write BIO finishes, this<br />
reminder BIO is unplugged and issued from the zone write plug work.<br />
If this reminder BIO itself needs to be split, the reminder will be<br />
re-issued and plugged again, but that causes a call to a<br />
blk_queue_enter(), which may block if a queue freeze operation was<br />
initiated. This results in a deadlock as DM submission still holds<br />
BIOs that the queue freeze side is waiting for.<br />
<br />
2) dm-crypt relies on the emulation done by the block layer using<br />
regular write operations for processing zone append operations. This<br />
still requires to properly return the written sector as the BIO<br />
sector of the original BIO. However, this can be done correctly only<br />
and only if there is a single clone BIO used for processing the<br />
original zone append operation issued by the user. If the size of a<br />
zone append operation is larger than dm-crypt max_write_size, then<br />
the orginal BIO will be split and processed as a chain of regular<br />
write operations. Such chaining result in an incorrect written sector<br />
being returned to the zone append issuer using the original BIO<br />
sector. This in turn results in file system data corruptions using<br />
xfs or btrfs.<br />
<br />
Fix this by modifying get_max_request_size() to always return the size<br />
of the BIO to avoid it being split with dm_accpet_partial_bio() in<br />
crypt_map(). get_max_request_size() is renamed to<br />
get_max_request_sectors() to clarify the unit of the value returned<br />
and its interface is changed to take a struct dm_target pointer and a<br />
pointer to the struct bio being processed. In addition to this change,<br />
to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt<br />
device max_hw_sectors limit to be at most<br />
BIO_MAX_VECS
Gravedad CVSS v3.1: MEDIA
Última modificación:
25/11/2025
