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