ghsa-f269-fccg-h65r
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
drivers: core: synchronize really_probe() and dev_uevent()
Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:
Thread #1:
really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }
Thread #2:
dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }
really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() 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:
dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_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.
{
"affected": [],
"aliases": [
"CVE-2024-39501"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-12T13:15:12Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: core: synchronize really_probe() and dev_uevent()\n\nSynchronize the dev-\u003edriver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u003edriver uninitialization:\n\nThread #1:\n==========\n\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n ...\n dev-\u003edriver = NULL; // \u003c= Failed probe sets dev-\u003edriver to NULL\n ...\n }\n...\n}\n\nThread #2:\n==========\n\ndev_uevent() {\n...\nif (dev-\u003edriver)\n // If dev-\u003edriver is NULLed from really_probe() from here on,\n // after above check, the system crashes\n add_uevent_var(env, \"DRIVER=%s\", dev-\u003edriver-\u003ename);\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\u0027t 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 \u003c= 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-\u003edriver\n\ndev-\u003edriver = drv;\n\nAs this switches dev-\u003edriver 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.",
"id": "GHSA-f269-fccg-h65r",
"modified": "2024-07-12T15:31:26Z",
"published": "2024-07-12T15:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08891eeaa97c079b7f95d60b62dcf0e3ce034b69"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/13d25e82b6d00d743c7961dcb260329f86bedf7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/760603e30bf19d7b4c28e9d81f18b54fa3b745ad"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95d03d369ea647b89e950667f1c3363ea6f564e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a42b0060d6ff2f7e59290a26d5f162a3c6329b90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb3641a5831789d83a58a39ed4a928bcbece7080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0a40097f0bc81deafc15f9195d1fb54595cd6d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec772ed7cb21b46fb132f89241682553efd0b721"
}
],
"schema_version": "1.4.0",
"severity": []
}
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.