ACK: [SRU][M][PATCH 0/1] CVE-2024-26704

Andrei Gherzan andrei.gherzan at canonical.com
Tue Apr 23 14:22:04 UTC 2024


On 24/04/19 04:28PM, Bethany Jamison wrote:
> [Impact]
> 
>  In the Linux kernel, the following vulnerability has been resolved:
> 
>  ext4: fix double-free of blocks due to wrong extents moved_len
> 
>  In ext4_move_extents(), moved_len is only updated when all moves are
>  successfully executed, and only discards orig_inode and donor_inode
>  preallocations when moved_len is not zero. When the loop fails to exit
>  after successfully moving some extents, moved_len is not updated and
>  remains at 0, so it does not discard the preallocations.
> 
>  If the moved extents overlap with the preallocated extents, the
>  overlapped extents are freed twice in ext4_mb_release_inode_pa() and
>  ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:
>  Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is
>  incremented twice. Hence when trim is executed, a zero-division bug is
>  triggered in mb_update_avg_fragment_size() because bb_free is not zero
>  and bb_fragments is zero.
> 
>  Therefore, update move_len after each extent move to avoid the issue.
> 
> [Fix]
> 
> Mantic:	Clean cherry-pick from linux-6.6.y
> Jammy:	pending
> Focal:	pending
> Bionic:	fix sent to esm ML
> Xenial:	fix sent to esm ML
> Trusty:	not-affected
> 
> [Test Case]
> 
> Compile and boot tested.
> 
> [Where problems could occur]
> 
> This fix affects those who use the Ext4 file system, and an issue with
> this fix would be visable to the user via a system crash.
> 
> Baokun Li (1):
>   ext4: fix double-free of blocks due to wrong extents moved_len
> 
>  fs/ext4/move_extent.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)

Acked-by: Andrei Gherzan <andrei.gherzan at canonical.com>

-- 
Andrei Gherzan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240423/7cca4e00/attachment-0001.sig>


More information about the kernel-team mailing list