CVE-2024-50014

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.