{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In 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 \u003e /sys/bus/platform/drivers/mipi-i3c-hci/unbind   # echo intel-lpss-i3c.0 \u003e /sys/bus/platform/drivers/mipi-i3c-hci/bind   WARNING: possible recursive locking detected   kworker/5:1/94 is trying to acquire lock:   ffff88811c810d78 (\u0026i3cbus-\u003elock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370   but task is already holding lock:   ffff88811c810d78 (\u0026i3cbus-\u003elock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0  Fix this by separating device creation from device registration. Populate desc-\u003edev 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-\u003edev during initial device population, or desc-\u003edev disappearing if registration fails.  The local list requires a list node, so add a list node member to struct i3c_device.",
  "id": "DEBIAN-CVE-2026-93202",
  "modified": "2026-09-18T04:47:30.089661074Z",
  "published": "2026-09-17T17:18:16.510Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-93202"
    }
  ],
  "upstream": [
    "CVE-2026-93202"
  ]
}