CVE-2022-48712

What it actually does

Improper error handling after a failed krealloc in ext4_fc_record_modified_inode allows silent memory corruption or triggers a kernel bug in the fast-commit path of the ext4 filesystem.

Why it matters to the business

Systems using ext4 with fast commits can experience unexpected kernel instability, crashes, or data corruption, leading to unplanned downtime and potential loss of filesystem integrity; the issue affects widely deployed Linux environments even though exploitation remains uncommon.

How an attack unfolds

An attacker with local access crafts a sequence of filesystem operations that exercise the fast-commit modified-inode recording path; when memory pressure causes krealloc to fail, the missing error check leaves stale pointers or inconsistent state that can be leveraged for further corruption or denial of service.

How to fix it

Update the Linux kernel to a version containing the fix for ext4 fast-commit error handling; for cilium/cilium deployments apply commit ca1af73ffe025e2ebdb6c8cd5b2cfb1909cb3b06 or later; disable fast commits on ext4 volumes as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Verify the running kernel version contains the ext4 fast-commit fix; confirm cilium/cilium is at commit ca1af73ffe025e2ebdb6c8cd5b2cfb1909cb3b06 or newer; review kernel build logs or module symbols for the corrected ext4_fc_record_modified_inode function.

Typical attack path

1. Obtain local access or execute code on a target system with an ext4 filesystem using fast commits
2. Trigger repeated inode modifications under memory pressure to force krealloc failure in ext4_fc_record_modified_inode
3. Exploit resulting memory corruption or kernel bug to cause panic or attempt privilege escalation

How to detect it

Search kernel logs for oops, BUG, or warning messages originating from ext4 fast-commit code paths; inspect system crash dumps for anomalies around inode tracking structures; review audit logs for unusual mount options or filesystem activity preceding instability.

What your security team should do

• Apply the kernel or cilium patch containing commit ca1af73ffe025e2ebdb6c8cd5b2cfb1909cb3b06 immediately on all affected systems
• Prioritize patching for any production workloads using ext4 fast commits
• Monitor vendor advisories for backported fixes in distribution kernels