CVE-2024-50014: ext4: fix access to uninitialised lock in fc replay path
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.
Security readout for executives and security teams
Plain-English summary
This Linux kernel ext4 issue can occur when mounting or recovering an ext4 filesystem that uses fast commits. The kernel may access a spinlock before it is initialized, producing a locking warning during replay. The public bundle does not show confirmed data loss, privilege escalation, or active exploitation.
Executive priority
Treat this as a targeted kernel maintenance issue unless your estate relies heavily on ext4 fast commit. There is no supplied evidence of active exploitation, but kernel filesystem defects still merit timely patching through normal Linux update channels.
Technical view
The flaw is in ext4 fast-commit replay. ext4_check_bdev_write_error() can try to lock sbi->s_bdev_wb_lock before __ext4_fill_super() initializes it. The upstream fix moves initialization earlier. The provided trace was triggered by fstest generic/629 against fast-commit-enabled ext4.
Likely exposure
Exposure appears limited to Linux systems using ext4 with the fast-commit feature and affected kernel builds listed in the CVE source bundle. Systems without ext4 fast commit, or already carrying the referenced stable fixes, are less likely to be exposed.
Exploitation context
No CISA KEV listing is provided, and the bundle contains no cited evidence of active exploitation or public weaponization. The reproduced condition comes from a filesystem test during mount/recovery, not from an attacker workflow described in the sources.
Researcher notes
The source evidence supports a lock-initialization ordering bug in the ext4 fast-commit replay path. Impact boundaries are not fully described: no CVSS, CWE, exploit prerequisites, crash confirmation, or confidentiality/integrity impact are included in the bundle.
Mitigation direction
Apply Linux kernel updates containing the referenced stable ext4 fixes.
Check distribution and device vendor advisories for backported kernel packages.
Prioritize hosts using ext4 fast commit on affected kernel lines.
Avoid assuming mitigation details not confirmed by your kernel vendor.
Validation and detection
Inventory Linux kernel versions across servers, appliances, and embedded systems.
Identify ext4 filesystems using the fast-commit feature.
Confirm installed kernels include the referenced upstream or vendor backported fixes.
Review boot and kernel logs for ext4 replay or lockdep warnings.
Track Debian LTS and Siemens guidance where those environments apply.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-50014 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.