In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel: serialize btintelhwerror() with hcireqsync_lock
btintelhwerror() issues two __hcicmdsync() calls (HCIOPRESET and Intel exception-info retrieval) without holding hcireqsynclock(). This lets it race against hcidevdoclose() -> btintelshutdowncombined(), which also runs __hcicmdsync() under the same lock. When both paths manipulate hdev->reqstatus/reqrsp concurrently, the close path may free the response skb first, and the still-running hwerror path hits a slab-use-after-free in kfreeskb().
Wrap the whole recovery sequence in hcireqsync_lock/unlock so it is serialized with every other synchronous HCI command issuer.
Below is the data race report and the kasan report:
BUG: data-race in _hcicmdsyncsk / btintelshutdowncombined
read of hdev->reqrsp at net/bluetooth/hcisync.c:199 by task kworker/u17:1/83: __hcicmdsyncsk+0x12f2/0x1c30 net/bluetooth/hcisync.c:200 __hcicmdsync+0x55/0x80 net/bluetooth/hcisync.c:223 btintelhwerror+0x114/0x670 drivers/bluetooth/btintel.c:254 hcierrorreset+0x348/0xa30 net/bluetooth/hcicore.c:1030
write/free by task ioctl/22580: btintelshutdowncombined+0xd0/0x360 drivers/bluetooth/btintel.c:3648 hcidevclosesync+0x9ae/0x2c10 net/bluetooth/hcisync.c:5246 hcidevdoclose+0x232/0x460 net/bluetooth/hcicore.c:526
BUG: KASAN: slab-use-after-free in skskbreason_drop+0x43/0x380 net/core/skbuff.c:1202 Read of size 4 at addr ffff888144a738dc by task kworker/u17:1/83: __hcicmdsyncsk+0x12f2/0x1c30 net/bluetooth/hcisync.c:200 _hcicmdsync+0x55/0x80 net/bluetooth/hcisync.c:223 btintelhwerror+0x186/0x670 drivers/bluetooth/btintel.c:260
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31500.json",
"cna_assigner": "Linux"
}