GHSA-W328-5F65-PQHC
Vulnerability from github – Published: 2026-09-17 18:32 – Updated: 2026-09-17 18:32In the Linux kernel, the following vulnerability has been resolved:
i3c: master: Fix recursive locking during device registration
i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read(). device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem. rwsems do not support recursive read locking and can deadlock when a writer is waiting. See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst.
For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like: # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind WARNING: possible recursive locking detected kworker/5:1/94 is trying to acquire lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370 but task is already holding lock: ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0
Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register(). Finally retake the lock and clean up any devices that failed to register.
Use the maintenance lock rather than the normal-use lock while adding device objects. A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails.
The local list requires a list node, so add a list node member to struct i3c_device.
{
"affected": [],
"aliases": [
"CVE-2026-93202"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-17T17:18:16Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ni3c: master: Fix recursive locking during device registration\n\ni3c_master_register_new_i3c_devs() registers newly discovered devices\nwhile holding i3c_bus_normaluse_lock(), a down_read(). device_register()\ncan immediately probe the device, and probe callbacks typically invoke\nI3C helpers that take i3c_bus_normaluse_lock() again, leading to a\nrecursive acquisition of the same rwsem. rwsems do not support recursive\nread locking and can deadlock when a writer is waiting. See the\n\"Recursive read locks\" section of Documentation/locking/lockdep-design.rst.\n\nFor example, with Intel LPSS I3C, LOCKDEP generates a WARNING like:\n # echo intel-lpss-i3c.0 \u003e /sys/bus/platform/drivers/mipi-i3c-hci/unbind\n # echo intel-lpss-i3c.0 \u003e /sys/bus/platform/drivers/mipi-i3c-hci/bind\n WARNING: possible recursive locking detected\n kworker/5:1/94 is trying to acquire lock:\n ffff88811c810d78 (\u0026i3cbus-\u003elock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370\n but task is already holding lock:\n ffff88811c810d78 (\u0026i3cbus-\u003elock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0\n\nFix this by separating device creation from device registration.\nPopulate desc-\u003edev under the maintenance lock, collect the devices that\nstill need registration into a local list, then release the lock before\ncalling device_register(). Finally retake the lock and clean up any\ndevices that failed to register.\n\nUse the maintenance lock rather than the normal-use lock while adding\ndevice objects. A write-side maintenance lock prevents readers from\nobserving a partially initialized desc-\u003edev during initial device\npopulation, or desc-\u003edev disappearing if registration fails.\n\nThe local list requires a list node, so add a list node member to struct\ni3c_device.",
"id": "GHSA-w328-5f65-pqhc",
"modified": "2026-09-17T18:32:14Z",
"published": "2026-09-17T18:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-93202"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/456f832e5fc26fbfd3b8200fd4553eee520cc377"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dc73c51ed3ee965c3ddb0ac31cf5c3eea68fa0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b25232f66e8cd653d0c6bfdbe534e62a2f9d6a1b"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.