CVE-2021-47117

What it actually does

The flaw triggers a kernel BUG_ON in ext4_es_cache_extent when ext4_split_extent_at fails during extent tree operations, resulting in an Oops crash during buffered reads and extent caching on ext4 filesystems.

Why it matters to the business

Unexpected system crashes or instability can occur during normal file reads on affected ext4 volumes, especially under I/O stress or fault injection, potentially disrupting workloads until the system is updated.

How an attack unfolds

An attacker with local access triggers the vulnerable code path by performing filesystem operations that cause an extent split to fail (such as ENOSPC or EDQUOT conditions) while reads are in progress, leading to the crash; the original report notes this was observed during fsstress testing with injected faults.

How to fix it

Upgrade gcc-toolset-10-ltrace on AlmaLinux 8 to version 0.7.91-1.el8 or later; apply the corresponding kernel update that resolves the ext4 extent handling issue after split failures.

How to confirm the fix worked

Confirm the installed package version meets or exceeds the fixed release, then exercise ext4 read workloads under memory or I/O pressure to verify absence of the BUG_ON in extents_status.c.

Typical attack path

1. Obtain local access to a system using an affected ext4 kernel
2. Perform or induce file reads combined with extent modifications that force split failures
3. Trigger the extent caching path that hits the BUG_ON
4. Cause kernel panic or denial of service

How to detect it

Review kernel logs for the signature BUG at fs/ext4/extents_status.c combined with the call trace containing ext4_es_cache_extent, ext4_cache_extents, and ext4_find_extent; examine dmesg or syslog for Oops entries during ext4 read operations.

What your security team should do

• Prioritize patching systems hosting ext4 filesystems within the next maintenance window
• Monitor for any remaining unpatched AlmaLinux 8 instances running gcc-toolset-10-ltrace
• Test the update in a staging environment with fsstress or similar I/O workloads before broad deployment