CVE-2023-52786

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