CVE-2026-45912

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t cache extent during splitting extent<br /> <br /> Caching extents during the splitting process is risky, as it may result<br /> in stale extents remaining in the status tree. Moreover, in most cases,<br /> the corresponding extent block entries are likely already cached before<br /> the split happens, making caching here not particularly useful.<br /> <br /> Assume we have an unwritten extent, and then DIO writes the first half.<br /> <br /> [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUUUUUU] extent status tree<br /> || ----&gt; dio write this range<br /> <br /> First, when ext4_split_extent_at() splits this extent, it truncates the<br /> existing extent and then inserts a new one. During this process, this<br /> extent status entry may be shrunk, and calls to ext4_find_extent() and<br /> ext4_cache_extents() may occur, which could potentially insert the<br /> truncated range as a hole into the extent status tree. After the split<br /> is completed, this hole is not replaced with the correct status.<br /> <br /> [UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUU|HHHHHHHH] extent status tree H: hole<br /> <br /> Then, the outer calling functions will not correct this remaining hole<br /> extent either. Finally, if we perform a delayed buffer write on this<br /> latter part, it will re-insert the delayed extent and cause an error in<br /> space accounting.<br /> <br /> In adition, if the unwritten extent cache is not shrunk during the<br /> splitting, ext4_cache_extents() also conflicts with existing extents<br /> when caching extents. In the future, we will add checks when caching<br /> extents, which will trigger a warning. Therefore, Do not cache extents<br /> that are being split.