CVE-2024-50015

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: dax: fix overflowing extents beyond inode size when partially writing<br /> <br /> The dax_iomap_rw() does two things in each iteration: map written blocks<br /> and copy user data to blocks. If the process is killed by user(See signal<br /> handling in dax_iomap_iter()), the copied data will be returned and added<br /> on inode size, which means that the length of written extents may exceed<br /> the inode size, then fsck will fail. An example is given as:<br /> <br /> dd if=/dev/urandom of=file bs=4M count=1<br /> dax_iomap_rw<br /> iomap_iter // round 1<br /> ext4_iomap_begin<br /> ext4_iomap_alloc // allocate 0~2M extents(written flag)<br /> dax_iomap_iter // copy 2M data<br /> iomap_iter // round 2<br /> iomap_iter_advance<br /> iter-&gt;pos += iter-&gt;processed // iter-&gt;pos = 2M<br /> ext4_iomap_begin<br /> ext4_iomap_alloc // allocate 2~4M extents(written flag)<br /> dax_iomap_iter<br /> fatal_signal_pending<br /> done = iter-&gt;pos - iocb-&gt;ki_pos // done = 2M<br /> ext4_handle_inode_extension<br /> ext4_update_inode_size // inode size = 2M<br /> <br /> fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?<br /> <br /> Fix the problem by truncating extents if the written length is smaller<br /> than expected.