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