kernel/linux.git/drivers/i3c, branch v6.1.124

i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition

2024-12-14T18:54:56+00:00

commit 61850725779709369c7e907ae8c7c75dc7cec4f3 upstream. In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove. Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void") Cc: stable@vger.kernel.org Signed-off-by: Kaixin Wang Reviewed-by: Miquel Raynal Reviewed-by: Frank Li Link: https://lore.kernel.org/stable/20240914154030.180-1-kxwang23%40m.fudan.edu.cn Link: https://lore.kernel.org/r/20240914163932.253-1-kxwang23@m.fudan.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: master: svc: fix possible assignment of the same address to two devices

2024-12-14T18:54:55+00:00

commit 3b2ac810d86eb96e882db80a3320a3848b133208 upstream. svc_i3c_master_do_daa() { ... for (i = 0; i < dev_nb; i++) { ret = i3c_master_add_i3c_dev_locked(m, addrs[i]); if (ret) goto rpm_out; } } If two devices (A and B) are detected in DAA and address 0xa is assigned to device A and 0xb to device B, a failure in i3c_master_add_i3c_dev_locked() for device A (addr: 0xa) could prevent device B (addr: 0xb) from being registered on the bus. The I3C stack might still consider 0xb a free address. If a subsequent Hotjoin occurs, 0xb might be assigned to Device A, causing both devices A and B to use the same address 0xb, violating the I3C specification. The return value for i3c_master_add_i3c_dev_locked() should not be checked because subsequent steps will scan the entire I3C bus, independent of whether i3c_master_add_i3c_dev_locked() returns success. If device A registration fails, there is still a chance to register device B. i3c_master_add_i3c_dev_locked() can reset DAA if a failure occurs while retrieving device information. Cc: stable@kernel.org Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry") Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241002-svc-i3c-hj-v6-6-7e6e1d3569ae@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin

2024-12-14T18:54:55+00:00

commit 36faa04ce3d9c962b4b29d285ad07ca29e2988e4 upstream. When a new device hotjoins, a new dynamic address is assigned. i3c_master_add_i3c_dev_locked() identifies that the device was previously attached to the bus and locates the olddev. i3c_master_add_i3c_dev_locked() { ... olddev = i3c_master_search_i3c_dev_duplicate(newdev); ... if (olddev) { ... i3c_dev_disable_ibi_locked(olddev); ^^^^^^ The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So remove it. } i3c_dev_free_ibi_locked(olddev); ^^^^^^^^ This function internally calls i3c_dev_disable_ibi_locked() function causing to send DISEC command with old Address. The olddev should not receive any commands on the i3c bus as it does not exist and has been assigned a new address. This will result in NACK or timeout. So, update the olddev->ibi->enabled flag to false to avoid DISEC with OldAddr. } Include part of Ravindra Yashvant Shinde's work: https://lore.kernel.org/linux-i3c/20240820151917.3904956-1-ravindra.yashvant.shinde@nxp.com/T/#u Fixes: 317bacf960a4 ("i3c: master: add enable(disable) hot join in sys entry") Co-developed-by: Ravindra Yashvant Shinde Signed-off-by: Ravindra Yashvant Shinde Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241001162232.223724-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

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

2024-12-14T18:54:48+00:00

[ Upstream commit 6cf7b65f7029914dc0cd7db86fac9ee5159008c6 ] 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 Signed-off-by: Defa Li Link: https://lore.kernel.org/r/20241107132549.25439-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request

2024-12-14T18:54:47+00:00

[ Upstream commit 6ca2738174e4ee44edb2ab2d86ce74f015a0cc32 ] Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup(). Prevent this my masking the ring interrupts before ring stop request. Signed-off-by: Jarkko Nikula Link: https://lore.kernel.org/r/20240920144432.62370-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: master: Fix dynamic address leak when 'assigned-address' is present

2024-12-14T18:54:28+00:00

[ Upstream commit 851bd21cdb55e727ab29280bc9f6b678164f802a ] If the DTS contains 'assigned-address', a dynamic address leak occurs during hotjoin events. Assume a device have assigned-address 0xb. - Device issue Hotjoin - Call i3c_master_do_daa() - Call driver xxx_do_daa() - Call i3c_master_get_free_addr() to get dynamic address 0x9 - i3c_master_add_i3c_dev_locked(0x9) - expected_dyn_addr = newdev->boardinfo->init_dyn_addr (0xb); - i3c_master_reattach_i3c_dev(newdev(0xb), old_dyn_addr(0x9)); - if (dev->info.dyn_addr != old_dyn_addr && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0x9 -> TRUE (!dev->boardinfo || ^^^^^^^^^^^^^^^ -> FALSE dev->info.dyn_addr != dev->boardinfo->init_dyn_addr)) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 0xb != 0xb -> FALSE ... i3c_bus_set_addr_slot_status(&master->bus, old_dyn_addr, I3C_ADDR_SLOT_FREE); ^^^ This will be skipped. So old_dyn_addr never free } - i3c_master_get_free_addr() will return increased sequence number. Remove dev->info.dyn_addr != dev->boardinfo->init_dyn_addr condition check. dev->info.dyn_addr should be checked before calling this function because i3c_master_setnewda_locked() has already been called and the target device has already accepted dyn_addr. It is too late to check if dyn_addr is free in i3c_master_reattach_i3c_dev(). Add check to ensure expected_dyn_addr is free before i3c_master_setnewda_locked(). Fixes: cc3a392d69b6 ("i3c: master: fix for SETDASA and DAA process") Cc: stable@kernel.org Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-3-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: master: Extend address status bit to 4 and add I3C_ADDR_SLOT_EXT_DESIRED

2024-12-14T18:54:27+00:00

[ Upstream commit 2f552fa280590e61bd3dbe66a7b54b99caa642a4 ] Extend the address status bit to 4 and introduce the I3C_ADDR_SLOT_EXT_DESIRED macro to indicate that a device prefers a specific address. This is generally set by the 'assigned-address' in the device tree source (dts) file. ┌────┬─────────────┬───┬─────────┬───┐ │S/Sr│ 7'h7E RnW=0 │ACK│ ENTDAA │ T ├────┐ └────┴─────────────┴───┴─────────┴───┘ │ ┌─────────────────────────────────────────┘ │ ┌──┬─────────────┬───┬─────────────────┬────────────────┬───┬─────────┐ └─►│Sr│7'h7E RnW=1 │ACK│48bit UID BCR DCR│Assign 7bit Addr│PAR│ ACK/NACK│ └──┴─────────────┴───┴─────────────────┴────────────────┴───┴─────────┘ Some master controllers (such as HCI) need to prepare the entire above transaction before sending it out to the I3C bus. This means that a 7-bit dynamic address needs to be allocated before knowing the target device's UID information. However, some I3C targets may request specific addresses (called as "init_dyn_addr"), which is typically specified by the DT-'s assigned-address property. Lower addresses having higher IBI priority. If it is available, i3c_bus_get_free_addr() preferably return a free address that is not in the list of desired addresses (called as "init_dyn_addr"). This allows the device with the "init_dyn_addr" to switch to its "init_dyn_addr" when it hot-joins the I3C bus. Otherwise, if the "init_dyn_addr" is already in use by another I3C device, the target device will not be able to switch to its desired address. If the previous step fails, fallback returning one of the remaining unassigned address, regardless of its state in the desired list. Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-2-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni Stable-dep-of: 851bd21cdb55 ("i3c: master: Fix dynamic address leak when 'assigned-address' is present") Signed-off-by: Sasha Levin

i3c: master: Replace hard code 2 with macro I3C_ADDR_SLOT_STATUS_BITS

2024-12-14T18:54:27+00:00

[ Upstream commit 16aed0a6520ba01b7d22c32e193fc1ec674f92d4 ] Replace the hardcoded value 2, which indicates 2 bits for I3C address status, with the predefined macro I3C_ADDR_SLOT_STATUS_BITS. Improve maintainability and extensibility of the code. Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241021-i3c_dts_assign-v8-1-4098b8bde01e@nxp.com Signed-off-by: Alexandre Belloni Stable-dep-of: 851bd21cdb55 ("i3c: master: Fix dynamic address leak when 'assigned-address' is present") Signed-off-by: Sasha Levin

i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter

2024-12-14T18:54:27+00:00

[ Upstream commit 25bc99be5fe53853053ceeaa328068c49dc1e799 ] Fix issue where disabling IBI on one device disables the entire IBI interrupt. Modify bit 7:0 of enabled_events to serve as an IBI enable counter, ensuring that the system IBI interrupt is disabled only when all I3C devices have IBI disabled. Cc: stable@kernel.org Fixes: 7ff730ca458e ("i3c: master: svc: enable the interrupt in the enable ibi function") Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241101165002.2479794-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: master: svc: use slow speed for first broadcast address

2024-12-14T18:54:27+00:00

[ Upstream commit 20ade67bb1645f5ce8f37fa79ddfebbc5b5b24ef ] I3C controller should support adjusting open drain timing for the first broadcast address to make I3C device working as a i2c device can see slow broadcast address to close its Spike Filter to change working at i3c mode. Signed-off-by: Carlos Song Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20240910051626.4052552-2-carlos.song@nxp.com Signed-off-by: Alexandre Belloni Stable-dep-of: 25bc99be5fe5 ("i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter") Signed-off-by: Sasha Levin