Re: [PATCH 3/3] tune2fs: Add bounds checking for extended attribute processing

Andreas Dilger <[email protected]> Fri, 31 Jul 2026 03:03:50 -0600
Newsgroups org.kernel.vger.linux-ext4
Message-ID <[email protected]>
On Jul 30, 2026, at 21:37, Josh Hunt <[email protected]> wrote:
>=20
> From: Kit Knox <[email protected]>
>=20
> Add validation to prevent buffer overflow when processing extended
> attributes:
>=20
> - Check ea_inode size against maximum (64KB) before reading
> - Validate xattr entry bounds before accessing next entry
>=20
> This prevents malformed filesystem images from causing out-of-bounds =
memory
> access during UUID or checksum updates.

This looks like it will result in a totally corrupted filesystem, rather =
than
just a bad extended attribute?

> Signed-off-by: Kit Knox <[email protected]>
> ---
> misc/tune2fs.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>=20
> diff --git a/misc/tune2fs.c b/misc/tune2fs.c
> index 3db57632..8c292686 100644
> --- a/misc/tune2fs.c
> +++ b/misc/tune2fs.c
> @@ -775,6 +782,9 @@ static int update_xattr_entry_hashes(ext2_filsys =
fs,
>  	errcode_t retval;
>=20
>  	while (entry < end && !EXT2_EXT_IS_LAST_ENTRY(entry)) {
> +	if ((char *)end < (char *)entry + sizeof(*entry))
> +		fatal_err(EXT2_ET_EA_BAD_NAME_LEN,
> +			  "xattr entry exceeds buffer bounds");
>  	if (entry->e_value_inum) {
>  	retval =3D ext2fs_ext_attr_hash_entry2(fs, entry, NULL,
>  					     &entry->e_hash);
> @@ -784,6 +794,9 @@ static int update_xattr_entry_hashes(ext2_filsys =
fs,
>  		}
>  		entry =3D EXT2_EXT_ATTR_NEXT(entry);
>  	}
> +	if (entry > end)
> +		fatal_err(EXT2_ET_EA_BAD_NAME_LEN,
> +			  "xattr entry exceeds buffer bounds");
>  	return modified;
>  }

If the tune2fs UUID update that is changing the checksums of all inodes =
and
xattrs in the filesystem is interrupted, this will leave a filesystem =
with
half (or whatever) inodes using the new checksum and half with the old =
checksum,
rendering it mostly useless.

It would be better to just skip these bad inodes during processing and =
leave
it to e2fsck to correct them.  At least the uncorrupted inodes in the =
filesystem
(presumably a majority) will still be usable, and these xattrs will have =
a bad
checksum and presumably not be used.

Cheers, Andreas