CVE-2026-72335

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

Bluetooth: MGMT: Fix adv monitor add failure cleanup

hciaddadvmonitor() publishes a new advmonitor in hdev->advmonitorsidr before the powered MSFT setup step. The MSFT offload add path can then fail either locally before the controller add command completes, or in the MSFT add callback. In the current queued management add flow, hcicmdsyncwork() still invokes mgmtaddadvpatternsmonitorcomplete() with the original pending command after msftaddmonitor_pattern() returns.

The buggy scenario involves two paths, with each column showing the order within that path:

MSFT add handling MGMT completion 1. insert monitor and handle 1. receive sync error 2. send MSFT add command 2. call add-monitor completion 3. callback sees bad response 3. load cmd->user_data 4. callback frees monitor 4. read monitor->handle

Local MSFT setup failures have the other half of the same ownership bug: they return an error after the IDR insertion, but no later code removes the failed monitor from the IDR.

Keep ownership with the pending management command until its completion. For normal management adds, the MSFT add callback now records successful controller state and returns errors to its caller. The management completion frees the monitor on non-success after copying the response handle, while resume/reregister callback-error cleanup remains in the MSFT callback. The success path keeps the existing bookkeeping.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in mgmtaddadvpatternsmonitor_complete+0xfb/0x260 [bluetooth]

Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x5f0 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] ? srsoaliasreturn_thunk+0x5/0xfbef5 ? __virtaddrvalid+0x19f/0x330 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] kasanreport+0xe0/0x110 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] ? srsoaliasreturn_thunk+0x5/0xfbef5 ? 0xffffffffc00d00da ? __pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] ? __pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] ? hcicmdsyncwork+0x1ab/0x210 [bluetooth] hcicmdsyncwork+0x1c0/0x210 [bluetooth] ? __pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] processonework+0x4fd/0xbc0 ? __pfxprocessone_work+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? __listaddvalidorreport+0x37/0xf0 ? __pfxhcicmdsyncwork+0x10/0x10 [bluetooth] ? srsoaliasreturnthunk+0x5/0xfbef5 workerthread+0x2d8/0x570 ? __pfxworkerthread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfxkthread+0x10/0x10 retfrom_fork+0x3c9/0x540 ? __pfxretfromfork+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 471 on cpu 3 at 285.205389s: kasansavestack+0x33/0x60 kasansavetrack+0x17/0x60 __kasankmalloc+0xaa/0xb0 addadv_patternsmonitorrssi+0xd5/0x230 [bluetooth] hcisocksendmsg+0x96b/0xf80 [bluetooth] __sys_sendto+0x2bc/0x2d0 __x64syssendto+0x76/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 454 on cpu 2 at 285.217112s: kasansavestack+0x33/0x60 kasansavetrack+0x17/0x60 kasansavefree_info+0x3b/0x60 _kasanslabfree+0x5f/0x80 kfree+0x313/0x590 msftaddmonitorsync+0x54a/0x570 [bluetooth] hciaddadvmonitor+0x133/0x180 [bluetooth] hcicmdsyncwork+0x187/0x210 [bluetooth] processonework+0x4fd/0xbc0 workerthread+0x2d8/0x570 kthread+0x1ad/0x1f0 retfromfork+0x3c9/0x540 retfromforkasm+0x1a/0x30