CVE-2024-43098

i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock

MEDIUM

5.5

CVSS Score

Published: January 11, 2025 at 12:25 PM UTC

Updated: June 17, 2026 at 07:50 AM UTC

1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available

Start Free Sign In

Severity

MEDIUM5.5

Exploit prediction

EPSS 0.2%

SSVC

No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

Linux Kernel · Linux

95%

5.0 ≤ v < 5.10.2315.0 ≤ v < 5.15.1745.0 ≤ v < 5.4.2875.0 ≤ v < 6.1.1205.0 ≤ v < 6.12.55.0 ≤ v < 6.135.0 ≤ v < 6.6.665.11 ≤ v < 5.15.1745.16 ≤ v < 6.1.1205.5 ≤ v < 5.10.2316.2 ≤ v < 6.6.666.7 ≤ v < 6.12.53a379bbcea0af6280e1ca0d1edfcf4e68cde6ee05.0

Vendor states this is fixed in 1f51ae217d09c361ede900b94735a6d2df6c0344 (fixed)

Vendor states this is fixed in 2d98fa2a50b8058de52ada168fa5dbabb574711b (fixed)

Vendor states this is fixed in 5ac1dd51aaa0ce8b5421d1137e857955a4b6f55e (fixed)

Vendor states this is fixed in 6cf7b65f7029914dc0cd7db86fac9ee5159008c6 (fixed)

Vendor states this is fixed in 816187b1833908941286e71b0041059a4acd52ed (fixed)

Vendor states this is fixed in 9a2173660ee53d5699744f02e6ab7bf89fcd0b1a (fixed)

Vendor states this is fixed in ffe19e363c6f8b992ba835a361542568dea17409 (fixed)

Vendor states this is fixed in 5.0 (unaffected)

Vendor states this is fixed in 5.10.231 (unaffected)

Vendor states this is fixed in 5.15.174 (unaffected)

Vendor states this is fixed in 5.4.287 (unaffected)

Vendor states this is fixed in 6.1.120 (unaffected)