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

drivers: core: synchronize reallyprobe() and devuevent()

Synchronize the dev->driver usage in reallyprobe() and devuevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:

Thread #1:

reallyprobe() { ... probefailed: ... deviceunbindcleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }

Thread #2:

devuevent() { ... if (dev->driver) // If dev->driver is NULLed from reallyprobe() from here on, // after above check, the system crashes addueventvar(env, "DRIVER=%s", dev->driver->name); ... }

reallyprobe() holds the lock, already. So nothing needs to be done there. devuevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:

devuevent+0x235/0x380 ueventshow+0x10c/0x1f0 <= Add lock here devattrshow+0x3a/0xa0 sysfskfseqshow+0x17c/0x250 kernfsseqshow+0x7c/0x90 seqreaditer+0x2d7/0x940 kernfsfopreaditer+0xc6/0x310 vfsread+0x5bc/0x6b0 ksysread+0xeb/0x1b0 _x64sysread+0x42/0x50 x64syscall+0x27ad/0x2d30 dosyscall64+0xcd/0x1d0 entrySYSCALL64after_hwframe+0x77/0x7f

Similar cases are reported by syzkaller in

https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a

But these are regarding the initialization of dev->driver

dev->driver = drv;

As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).

The same issue was reported and tried to be fixed back in 2015 in

https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/

already.