Mercredi 21 octobre 2026

Linux

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown hci_low_sent() selects a connection under RCU but drops the read lock before calculating its quota and returning it to the scheduler. The connection is then used without lifetime protection by hci_sched_iso() and hci_sched_sco(). After the TX worker drops the RCU read lock, hci_abort_conn_sync() on hdev->req_workqueue can remove the connection from the hash, complete synchronize_rcu(), purge its queues and release it. The TX worker on hdev->workqueue can then access the freed connection in hci_quote_sent() or while dequeuing packets and updating conn->sent. KASAN reported: BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840 Workqueue: hci0 hci_tx_work Call Trace: hci_low_sent+0x730/0x840 hci_sched_iso+0x25e/0x4d0 hci_tx_work+0x239/0xcb0 Allocated by task 93: __hci_conn_add+0x16f/0x1b40 hci_bind_bis+0x782/0x17b0 hci_connect_bis+0xa0/0x510 iso_sock_connect+0x589/0x1050 Freed by task 88: kfree+0x131/0x3c0 device_release+0xc8/0x240 kobject_put+0x14d/0x280 hci_conn_del+0x55a/0xe80 hci_disconnect_sync+0x156/0x180 hci_abort_conn_sync+0x3e7/0x940 hci_cmd_sync_work+0x13c/0x290 Hold hci_dev_lock() across connection selection and transmission in both SCO and ISO scheduling, serializing them with connection teardown. This also prevents queuing completion timestamps after the connection queues have been purged. Extending RCU across transmission would be unsafe because the transmit path can sleep. Keep the ISO timeout check outside the mutex since hci_link_tx_to() takes it itself. The preceding channel fix already holds this mutex in the ACL and LE schedulers, which call the SCO scheduler between packets. Move the SCO body to __hci_sched_sco(), assert that its caller holds the mutex, and use it directly from these locked paths. Keep a locking hci_sched_sco() wrapper for the direct calls from hci_tx_work(). This avoids recursively acquiring the device mutex while preserving the scheduling order. Remove the obsolete claim that connection removal disables TX.

Linux

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.

Linux

In the Linux kernel, the following vulnerability has been resolved: HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer(). sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb(): timer_delete_sync(&sc->ghl_poke_timer); usb_free_urb(sc->ghl_urb); timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race. Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed. Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later: BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0 Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0 ghl_magic_poke+0x98/0xb0 call_timer_fn+0x35/0x2b0 __run_timers+0x69c/0x9a0 run_timer_softirq+0x173/0x2a0 Allocated by task 169: sony_probe Freed by task 338: devres_release_group <- hid_device_remove (sony_remove) Found by 0sec (https://0sec.ai) using automated source analysis.