CVE-2024-50191

What it actually does

ext4 sets the SB_RDONLY flag without sb->s_umount locking when errors=remount-ro is active, bypassing the normal remount path and leaving filesystem freeze state machines inconsistent once EXT4_FLAGS_SHUTDOWN is also set.

Why it matters to the business

Low-severity stability issue on Linux systems using ext4; may produce spurious warnings during error recovery but does not enable data loss or remote compromise; widespread kernel deployments increase the number of potentially affected hosts.

How an attack unfolds

An attacker or automated fuzzer mounts an ext4 filesystem with errors=remount-ro, induces a filesystem error to trigger the remount-ro path, then initiates a freeze operation; the unlocked SB_RDONLY change confuses the freeze code and surfaces warnings.

How to fix it

Upgrade the Linux kernel to a version containing commit 58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9; no configuration change is required after the update.

How to confirm the fix worked

Confirm the presence of commit 58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9 in the running kernel source or via kernel version string; re-test error-injection plus freeze sequences to verify absence of warnings.

Typical attack path

1. Mount ext4 volume with errors=remount-ro option
2. Trigger a filesystem error condition
3. Initiate a filesystem freeze via ioctl or internal call
4. Observe lockdep or warning output from mismatched SB_RDONLY state

How to detect it

Search kernel logs for ext4 freeze-related warnings on systems that have encountered filesystem errors; correlate with mount options containing errors=remount-ro.

What your security team should do

• Apply the referenced kernel update during the next maintenance window
• Review ext4 mount options and consider errors=panic for critical systems if warnings persist
• Add kernel warning patterns for ext4 freeze operations to monitoring rules