CVE-2026-98735: Bluetooth: hci_core: Serialize ACL scheduling with channel deletion

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

Bluetooth: hcicore: Serialize ACL scheduling with channel deletion

hcichansent() 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 hciconnfailed() and l2capconndel(). hcichandel() can then unlink the channel, complete synchronizercu(), purge its queue and free it before TX resumes. This causes use-after-free both in hcichansent() and in its callers.

KASAN reported:

BUG: KASAN: slab-use-after-free in hcichansent+0x892/0x9b0 Workqueue: hci0 hcitxwork Call Trace: hcichansent+0x892/0x9b0 hcitxwork+0x5e6/0xb70 Allocated by task 91: hcichancreate+0xe3/0x350 l2capconnadd.part.0+0x12/0xa30 l2capchanconnect+0x110d/0x1b60 l2capsockconnect+0x310/0x530 Freed by task 99: hcichandel+0x11f/0x170 l2capconndel+0x4f1/0x800 l2capconnectcfm+0x88c/0xd30 hciconnfailed+0x150/0x250 hciabortconnsync+0x3e3/0x800 hcicmdsyncrun+0x7e/0xc0 hciabortconn+0x105/0x1f0 disconnectsync+0x157/0x290 hcicmdsyncwork+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 hcilinktxto() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission.