CVE-2025-39791

*** 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