CVE-2021-46945 - Linux Kernel ext4 Filesystem Panic Vulnerability Explained

The Linux kernel is the core of most Unix-like operating systems, including many distributions you use every day. One important part of the kernel is the ext4 filesystem driver. In early 2021, a subtle but impactful issue was identified regarding how ext4 reacts to errors based on its mount options. This vulnerability is tracked as CVE-2021-46945.

In this article, we’ll break down what the issue was, how it could be triggered, how it was fixed, and why it matters for server admins and security professionals.

What’s the Vulnerability? (Simple Terms)

CVE-2021-46945 deals with how the ext4 filesystem handles serious disk errors when it’s configured to “panic” on trouble.

The ext4 filesystem has a special mount option, errors=panic, that tells the kernel to immediately stop everything and panic if some critical filesystem error is detected. This is usually a last-resort safety feature—when you set it, you'd expect any error to halt the system so things don’t get even more corrupted.

Before a code change in 2021, some error-triggering operations did *not* cause the kernel to panic as expected, creating an inconsistent (and potentially dangerous) state. That’s what this CVE covers.

Here’s how you could test for the bug before it was fixed (kernel prior to commit 014c9caa29d3)

# Mount a device as read-only with "panic on error"
mount /dev/sda -o ro,errors=panic /mnt/test

# Remount the filesystem with the "abort" mount option
mount /dev/sda -o remount,abort /mnt/test

*Expected Result:*
Before the vulnerability was fixed, the above commands would NOT always cause an immediate kernel panic, even though errors=panic was set.

What the "Abort" Option Does

The "abort" option for mount is meant to simulate a filesystem error (for developers or testers), as if the disk just trashed itself.

After the fix, you can also trigger a panic using the trigger_fs_error interface

# Mount the device as above
mount /dev/sda -o ro,errors=panic /mnt/test

# Now trigger a filesystem error deliberately:
echo test > /sys/fs/ext4/sda/trigger_fs_error

*Expected Result (after fix):*
Now the system will immediately panic, as expected with errors=panic.

Why Is This Important?

- Consistency: Proving errors=panic means *really* panic instantly on a filesystem error, no matter how it’s triggered (mount options, triggered error, etc).
- Predictable Behavior: Sysadmins and engineers rely on well-defined panic mechanics. Any deviation could mean silent corruption or missed alerting.
- Security: While this isn’t a classic "remote code execution" or "privilege escalation" bug, refusing to panic on error can lead to data loss, corrupted backups, or hard-to-detect filesystem damages.

Relevant Patch

The bug was introduced when the developer refactored error handling. The commit 014c9caa29d3 (ext4: make ext4_abort() use __ext4_error()) broke the immediate panic behavior.

The fix simply restores older behavior, *guaranteeing* a panic for all error paths when errors=panic is set. This restores consistency, and makes the filesystem error handling more fool-proof.

Example code snippet from the patch

if (test_opt(sb, ERRORS_PANIC)) {
    panic("EXT4-fs (device %s): panic forced after error\n", sb->s_id);
}

Now, any error routed through ext4's error handler with errors=panic will reliably halt the kernel.

References

- Kernel.org Bugzilla: CVE-2021-46945
- Upstream Linux Kernel Patch
- ext4 Documentation
- VulDB Entry

Exploit Details

While not a classic code exploit, an attacker with (local) shell access—root or otherwise able to use mount commands—could exploit this inconsistency to prevent kernel panic on fatal disk issues. For instance, a rootkit or ransomware might deliberately mask errors to avoid attracting attention.

A proof-of-concept is as simple as

mount /dev/sda -o ro,errors=panic /mnt/test
mount /dev/sda -o remount,abort /mnt/test
# -- Old kernels wouldn't always panic here

Or

mount /dev/sda -o ro,errors=panic /mnt/test
echo test > /sys/fs/ext4/sda/trigger_fs_error
# -- Now always causes kernel panic

Who is Affected?

- Kernel users running affected kernel versions (mostly mainline Linux and distributions shipping ext4 between kernel 5.x and the fix).
- Systems using the errors=panic mount option rely on this for high-reliability production settings (think: banking, medical systems, big storage arrays).

Update your kernel: All major distros have patched kernels available. Update!

- Audit mount options: Double check your /etc/fstab and operational policies.
- Monitor logs: If a panic is unexpectedly missing/present in ext4 error situations, review your kernel’s patch status.

Final Thoughts

CVE-2021-46945 might seem minor, but for server reliability and security, even these “boring” details matter. The Linux ecosystem benefits from clear, consistent error handling, so updates like these can save hours of headaches for sysadmins everywhere.

Remember: even when you want a panic, make sure the panic *really* happens!

Timeline

Published on: 02/27/2024 19:04:06 UTC
Last modified on: 04/10/2024 20:11:52 UTC