"value":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: core: synchronize really_probe() and dev_uevent()\n\nSynchronize the dev->driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev->driver uninitialization:\n\nThread #1:\n==========\n\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n ...\n dev->driver = NULL; // <= Failed probe sets dev->driver to NULL\n ...\n }\n...\n}\n\nThread #2:\n==========\n\ndev_uevent() {\n...\nif (dev->driver)\n // If dev->driver is NULLed from really_probe() from here on,\n // after above check, the system crashes\n add_uevent_var(env, \"DRIVER=%s\", dev->driver->name);\n...\n}\n\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can't add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\n\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0 <= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nSimilar cases are reported by syzkaller in\n\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\n\nBut these are regarding the *initialization* of dev->driver\n\ndev->driver = drv;\n\nAs this switches dev->driver to non-NULL these reports can be considered\nto be false-positives (which should be \"fixed\" by this commit, as well,\nthough).\n\nThe same issue was reported and tried to be fixed back in 2015 in\n\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\n\nalready."
