CVE-2024-50014

What it actually does

In the Linux kernel ext4 fast-commit replay path, ext4_check_bdev_write_error attempts to acquire sbi->s_bdev_wb_lock before the spinlock has been initialized in __ext4_fill_super, resulting in access to an uninitialised lock object.

Why it matters to the business

Systems running affected kernels may experience kernel panics or lockdep warnings during mount of ext4 filesystems with fast-commit enabled, leading to boot failures or service disruption; the issue is long-published with low exploitation probability and no known ransomware or KEV usage.

How an attack unfolds

An attacker with the ability to trigger mount of a specially prepared ext4 filesystem with fast-commit enabled can cause the replay code path to execute before lock initialization, resulting in the observed lockdep splat; listed threat actor references appear generic and unrelated to confirmed exploitation of this specific flaw.

How to fix it

Update to a kernel containing commit 6e35f560daebe40264c95e9a1ab03110d4997df6 or later; ensure the spinlock initialization is moved earlier in __ext4_fill_super before any replay paths can execute.

How to confirm the fix worked

Confirm the running kernel includes the fix commit; attempt to mount an ext4 filesystem with fast-commit enabled under the same fstest conditions (generic/629) and verify absence of the register_lock_class splat.

Typical attack path

1. Prepare or obtain an ext4 filesystem image with fast-commit feature enabled
2. Trigger mount operation against the image on an affected kernel
3. Kernel executes jbd2_journal_recover which calls ext4_fc_replay
4. ext4_ext_replay_set_iblocks invokes ext4_reserve_inode_write which calls __ext4_journal_get_write_access
5. Lock acquisition on the uninitialised s_bdev_wb_lock occurs, producing the warning or panic

How to detect it

Review kernel logs for the exact lockdep message mentioning register_lock_class and __ext4_journal_get_write_access during mount; correlate with ext4_fc_replay call traces on systems that have fast-commit enabled.

• INFO: trying to register non-static key
• ext4_fc_replay
• __ext4_journal_get_write_access
• ext4_ext_replay_set_iblocks

What your security team should do

• Prioritize kernel upgrades on systems using ext4 with fast-commit feature
• Monitor for related kernel oops or lockdep messages during filesystem mount operations
• Apply the specific fixed commit 6e35f560daebe40264c95e9a1ab03110d4997df6 where source builds are used