In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninitialized ratelimitstate->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, " ext4msg _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); rawspinlock_init(&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 registerlockclass+0x740/0x7c0 lockacquire+0x69/0x13a0 lockacquire+0x120/0x450 _rawspintrylock+0x98/0xd0 _ratelimit+0xf6/0x220 _ext4msg+0x7f/0x160 [ext4] ext4orphancleanup+0x665/0x740 [ext4] _ext4fillsuper+0x21ea/0x2b10 [ext4] ext4fillsuper+0x14d/0x360 [ext4]
Normally interval is 0 until smsgratelimitstate 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 ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.