In the Linux kernel, the following vulnerability has been resolved:

ext4: fix uninitialized ratelimit_state->lock access in __ext4fillsuper()

In the following concurrency we will access the uninitialized rs->lock:

ext4fillsuper ext4registersysfs // sysfs registered msgratelimitintervalms // Other processes modify rs->interval to // non-zero via msgratelimitintervalms ext4orphancleanup ext4msg(sb, KERNINFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4SB(sb)->smsgratelimitstate) if (!rs->interval) // do nothing if interval is 0 return 1; rawspintrylockirqsave(&rs->lock, flags) rawspintrylock(lock) rawspintrylock rawspintrylock spinacquire(&lock->depmap, 0, 1, RETIP) lockacquire __lockacquire registerlockclass assignlockkey dumpstack(); ratelimitstateinit(&sbi->smsgratelimitstate, 5 * HZ, 10); rawspinlockinit(&rs->lock); // init rs->lock here

and get the following dump_stack:

========================================================= 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: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace: dumpstacklvl+0xc5/0x170 dumpstack+0x18/0x30 registerlock_class+0x740/0x7c0 __lockacquire+0x69/0x13a0 lockacquire+0x120/0x450 rawspin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4msg+0x7f/0x160 [ext4] ext4orphan_cleanup+0x665/0x740 [ext4] __ext4fillsuper+0x21ea/0x2b10 [ext4] ext4fillsuper+0x14d/0x360 [ext4]

[...]

Normally interval is 0 until smsgratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msgratelimitintervalms interface of sysfs while rs->lock is uninitialized, and then a call to ext4msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.