CVE-2021-47116

What it actually does

Memory leak in ext4_mb_init_backend error path when processing a corrupted filesystem superblock containing an illegally large s_log_groups_per_flex value, leaving allocated structures unreleased.

Why it matters to the business

Mounting malformed ext4 volumes on systems with the affected packages can lead to gradual memory exhaustion and potential system instability over time; low urgency due to stable low EPSS, no KEV listing, and publication over two years ago with no known threat actor exploitation.

How an attack unfolds

An attacker supplies a crafted ext4 filesystem image with an oversized s_log_groups_per_flex field; when the image is mounted, the kernel initialization routine hits the error path and leaks memory without recovery.

How to fix it

Upgrade gcc-toolset-10-make and gcc-toolset-10-make-devel on AlmaLinux 8 to version 1:4.2.1-1.el8 or newer; apply all subsequent kernel and filesystem updates.

How to confirm the fix worked

Confirm package versions meet or exceed the fixed releases; attempt to mount a test filesystem with oversized s_log_groups_per_flex and verify no memory growth occurs.

Typical attack path

1. Construct ext4 filesystem image containing illegal s_log_groups_per_flex value
2. Induce target system to mount the malicious image
3. Trigger ext4_mb_init_backend error handling to cause leak

How to detect it

Monitor kernel logs for ext4 mount failures referencing s_log_groups_per_flex or mb_init_backend; track process memory growth during filesystem initialization; no public exploitation artifacts exist.

What your security team should do

• Apply the listed package updates on all AlmaLinux 8 systems
• Restrict mounting of untrusted ext4 volumes until patched
• Review ext4 mount logs for repeated initialization failures