CVE-2024-35807

What it actually does

The ext4 online resize code in ext4_flex_group_add fails to correctly update backup block group descriptors when adding groups that straddle a meta block group boundary after resize_inode has been disabled, resulting in metadata corruption at the location of the meta block group's backup descriptors.

Why it matters to the business

Systems performing online filesystem expansion on ext4 volumes larger than 16 TiB (or smaller volumes with resize_inode explicitly disabled) risk silent data corruption that can render files unreadable and require offline repair or restore from backup.

How an attack unfolds

An attacker with local access triggers an online resize that crosses an 8 GiB meta-block-group boundary on a filesystem configured without resize_inode; the kernel writes the new group descriptors using the wrong layout, corrupting the backup descriptors for the meta block group and causing subsequent reads of affected metadata to return inconsistent data.

How to fix it

Upgrade the Linux kernel to a version containing commit 75cc31c2e7193b69f5d25650bda5bb42ed92f8a1 or later; after the update, perform filesystem checks on any volumes that were resized while running the vulnerable code.

How to confirm the fix worked

Confirm the running kernel contains commit 75cc31c2e7193b69f5d25650bda5bb42ed92f8a1, then repeat the resize operation across a meta block group boundary on a test filesystem and verify that file checksums remain unchanged after dropping caches.

Typical attack path

1. Obtain local access to a system with an ext4 filesystem larger than 16 TiB or with resize_inode disabled
2. Mount the filesystem and issue a resize2fs command that crosses a meta block group boundary
3. Force page-cache drop to reload blocks from disk
4. Observe checksum mismatches or filesystem corruption at physical block locations corresponding to meta block group backups

How to detect it

Review kernel logs for ext4 resize operations that cross 8 GiB boundaries on filesystems with meta_bg enabled; look for subsequent ext4 error messages about invalid block descriptors or checksum failures on group descriptor blocks after a resize completes.

What your security team should do

• Prioritize kernel updates on any hosts that host ext4 filesystems exceeding 16 TiB or that disable resize_inode
• Schedule post-upgrade fsck on volumes previously resized while vulnerable
• Monitor resize2fs invocations in privileged logs until patches are deployed