In the Linux kernel, the following vulnerability has been resolved:
ext4: check dot and dotdot of dx_root before making dir indexed
The immediate cause of this problem is that there is only one valid dentry
for the block to be split during do_split, so split==0 results in out of
bounds accesses to the map triggering the issue.
do_split
unsigned split
dx_make_map
count = 1
split = count/2 = 0;
continued = hash2 == map[split - 1].hash;
---> map[4294967295]
The maximum length of a filename is 255 and the minimum block size is 1024,
so it is always guaranteed that the number of entries is greater than or
equal to 2 when do_split() is called.
But syzbot’s crafted image has no dot and dotdot in dir, and the dentry
distribution in dirblock is as follows:
bus dentry1 hole dentry2 free
|xx–|xx-------------|…|xx-------------|…|
0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024
So when renaming dentry1 increases its name_len length by 1, neither hole
nor free is sufficient to hold the new dentry, and make_indexed_dir() is
called.
In make_indexed_dir() it is assumed that the first two entries of the
dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root
because they are treated as dot and dotdot, and only dentry2 is moved
to the new leaf block. That’s why count is equal to 1.
Therefore add the ext4_check_dx_root() helper function to add more sanity
checks to dot and dotdot before starting the conversion to avoid the above
issue.
git.kernel.org/stable/c/19e13b4d7f0303186fcc891aba8d0de7c8fdbda8
git.kernel.org/stable/c/42d420517072028fb0eb852c358056b7717ba5aa
git.kernel.org/stable/c/50ea741def587a64e08879ce6c6a30131f7111e7
git.kernel.org/stable/c/8afe06ed3be7a874b3cd82ef5f8959aca8d6429a
git.kernel.org/stable/c/9d241b7a39af192d1bb422714a458982c7cc67a2
git.kernel.org/stable/c/abb411ac991810c0bcbe51c2e76d2502bf611b5c
git.kernel.org/stable/c/b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db
git.kernel.org/stable/c/cdd345321699042ece4a9d2e70754d2397d378c5
security-tracker.debian.org/tracker/CVE-2024-42305