Re: [PATCH v14 06/12] ext4: refactor dx_root to support variable dirent sizes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ext4: dx_get_dx_info() offset shifts after dotdot rec_len update
--

commit 73068d5241d832480befa7394ccb6a8830dc1e0f
Author: Artem Blagodarenko <artem.blagodarenko@gmail.com>

ext4: refactor dx_root to support variable dirent sizes

This commit splits struct dx_root_info out of struct dx_root and introduces
ext4_dir_entry_len() and dx_get_dx_info() so that the htree root header can
follow variable-sized "." and ".." entries carrying dirdata.

[Severity: High]
In fs/ext4/namei.c, can the offset returned by dx_get_dx_info() shift after
make_indexed_dir() expands dotdot_de->rec_len to cover the rest of the block?

When __ext4_add_entry() calls make_indexed_dir() on a full one-block
unindexed directory, make_indexed_dir() calls dx_get_dx_info(dir, dot_de) at
line 2323 while dotdot_de->rec_len still holds its small pre-conversion
length (for example, 12 bytes).

Inside dx_get_dx_info() at line 556, the end of the ".." entry is computed by
calling ext4_dir_entry_len(de, blocksize, NULL), which in turn calls
ext4_dirent_get_data_len(de, rec_len) in fs/ext4/ext4.h. In
ext4_dirent_get_data_len(), the dirdata header for ".." starts at offset 11
(EXT4_BASE_DIR_LEN + 2 + 1). If dotdot_de->file_type has a dirdata flag bit
set in ~EXT4_FT_MASK and byte 11 of dotdot_de (ddh_length) is 2 or greater,
the check ddh_len > rec_len - offset evaluates to true while rec_len is 12,
causing ext4_dirent_get_data_len() to return 0 instead of an error.

As a result, dx_get_dx_info() treats dotdot_de as a 12-byte entry with no
dirdata and places dx_info immediately after it (for example, at offset 24).
make_indexed_dir() then wipes the block starting from offset 24, leaving
dotdot_de intact, and at line 2362 updates dotdot_de->rec_len to cover the
remainder of the block (for example, 4084 bytes) before writing dx_info at
offset 24 and the root dx_entry array at offset 32.

Once dotdot_de->rec_len is expanded to 4084, the bounds check ddh_len <=
rec_len - 11 in ext4_dirent_get_data_len() now succeeds, so subsequent calls
to ext4_dir_entry_len() and dx_get_dx_info() (such as in dx_release() at line
2424 and dx_probe() at line 853, as well as dx_root_limit() and
get_dx_countlimit() in later patches of this series) see a non-zero dirdata
length and compute a shifted dx_root_info offset pointing into the dx_entry
array or fail with -EFSCORRUPTED.

Should make_indexed_dir() or ext4_check_dx_root() validate or clear any
inconsistent dirdata flags on "." and ".." before expanding dotdot_de->rec_len
so that dx_get_dx_info() computes the same offset before and after conversion?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103134921.610047-1-ablagodarenko@thelustrecollective.com?part=6