GHSA-VFGJ-F4G9-XH2H
Vulnerability from github – Published: 2025-12-30 15:30 – Updated: 2025-12-30 15:30In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential null-ptr-deref in device_add()
I got the following null-ptr-deref report while doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]
This is how it happened:
w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device.
// error path
bus_remove_device()
// The dev->driver is not null, but driver is not bound.
__device_release_driver()
klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.
// normal path
bus_probe_device() // It's not called yet.
device_bind_driver()
If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().
{
"affected": [],
"aliases": [
"CVE-2023-54321"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-30T13:16:21Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n \u003cTASK\u003e\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n // The dev-\u003edriver is set to w1_master_driver.\n memcpy(\u0026dev-\u003edev, device, sizeof(struct device));\n device_add()\n bus_add_device()\n dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n // error path\n bus_remove_device()\n // The dev-\u003edriver is not null, but driver is not bound.\n __device_release_driver()\n klist_remove(\u0026dev-\u003ep-\u003eknode_driver) \u003c-- It causes null-ptr-deref.\n\n // normal path\n bus_probe_device() // It\u0027s not called yet.\n device_bind_driver()\n\nIf dev-\u003edriver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the \u0027knode_driver\u0027. To fix this, set\ndev-\u003edriver to null in the error path before calling bus_remove_device().",
"id": "GHSA-vfgj-f4g9-xh2h",
"modified": "2025-12-30T15:30:36Z",
"published": "2025-12-30T15:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54321"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17982304806c5c10924e73f7ca5556e0d7378452"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2c59650d078b1b3f1ea50d5f8ee9fcc537dc02d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cf515bf9e8c2908dc170ecf2df117162a16c9c5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6837f34a34973ef6600c08195ed300e24e97317"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.