Cloudanix VulnDB

CVE-2026-93202

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A locking mistake in the Linux kernel can cause certain hardware communication components to hang the system when new devices are detected.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Recursive acquisition of i3c_bus_normaluse_lock rwsem during i3c_master_register_new_i3c_devs device registration, which can deadlock when a writer waits because rwsems prohibit recursive read locks.

Why it matters to the business

Potential system hangs or crashes on Linux hosts using I3C controllers during device discovery or driver bind/unbind operations, leading to reduced availability for affected embedded or server platforms.

How an attack unfolds

An attacker with local access triggers device unbind and bind operations (or relies on normal device enumeration) that invoke i3c_master_register_new_i3c_devs while the lock is already held, causing recursive read attempts and deadlock under lockdep conditions.

How to fix it

Apply the upstream fix that separates device creation under the maintenance lock from registration under the normal-use lock, or upgrade to a kernel containing the resolution for this locking defect.

How to confirm the fix worked

Reproduce bind/unbind cycles on affected hardware and confirm absence of lockdep recursive locking warnings; inspect kernel source for the list node addition to struct i3c_device and the updated registration flow.

Typical attack path

  1. Obtain local access to a system with an I3C controller driver loaded
  2. Trigger driver unbind via sysfs or equivalent interface
  3. Re-bind the driver to force device registration path
  4. Observe recursive lock acquisition during probe callbacks

How to detect it

Search kernel logs for lockdep warnings referencing i3c_bus_normaluse_lock and i3c_master_reg_work_fn or i3c_device_match_id during platform driver bind operations.

  • WARNING: possible recursive locking detected
  • i3c_device_match_id+0x45/0x370
  • i3c_master_reg_work_fn+0x21/0x5f0
  • &i3cbus->lock){++++}-{4:4}

What your security team should do

  • Prioritize kernel updates on systems exposing I3C controllers to external or untrusted workloads
  • Monitor for lockdep warnings in dmesg on I3C-enabled platforms
  • Test driver reload sequences in staging environments before production rollout

The record

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 > /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 packages

Ecosystem Package Introduced Fixed