CVE-2023-52786

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix racy may inline data check in dio write<br /> <br /> syzbot reports that the following warning from ext4_iomap_begin()<br /> triggers as of the commit referenced below:<br /> <br /> if (WARN_ON_ONCE(ext4_has_inline_data(inode)))<br /> return -ERANGE;<br /> <br /> This occurs during a dio write, which is never expected to encounter<br /> an inode with inline data. To enforce this behavior,<br /> ext4_dio_write_iter() checks the current inline state of the inode<br /> and clears the MAY_INLINE_DATA state flag to either fall back to<br /> buffered writes, or enforce that any other writers in progress on<br /> the inode are not allowed to create inline data.<br /> <br /> The problem is that the check for existing inline data and the state<br /> flag can span a lock cycle. For example, if the ilock is originally<br /> locked shared and subsequently upgraded to exclusive, another writer<br /> may have reacquired the lock and created inline data before the dio<br /> write task acquires the lock and proceeds.<br /> <br /> The commit referenced below loosens the lock requirements to allow<br /> some forms of unaligned dio writes to occur under shared lock, but<br /> AFAICT the inline data check was technically already racy for any<br /> dio write that would have involved a lock cycle. Regardless, lift<br /> clearing of the state bit to the same lock critical section that<br /> checks for preexisting inline data on the inode to close the race.