CVE-2026-98735

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci core: Serialize ACL scheduling with channel deletion

hci chan sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion.

After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci conn failed() and l2cap conn del(). hci chan del() can then unlink the channel, complete synchronize rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci chan sent() and in its callers.

KASAN reported:

BUG: KASAN: slab-use-after-free in hci chan sent+0x892/0x9b0 Workqueue: hci0 hci tx work Call Trace: hci chan sent+0x892/0x9b0 hci tx work+0x5e6/0xb70 Allocated by task 91: hci chan create+0xe3/0x350 l2cap conn add.part.0+0x12/0xa30 l2cap chan connect+0x110d/0x1b60 l2cap sock connect+0x310/0x530 Freed by task 99: hci chan del+0x11f/0x170 l2cap conn del+0x4f1/0x800 l2cap connect cfm+0x88c/0xd30 hci conn failed+0x150/0x250 hci abort conn sync+0x3e3/0x800 hci cmd sync run+0x7e/0xc0 hci abort conn+0x105/0x1f0 disconnect sync+0x157/0x290 hci cmd sync work+0x13c/0x290

Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci link tx to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission.