CVE-2026-11368: Use-after-free in Bluetooth host ATT TX completion on disconnect mid-transfer

The Bluetooth host ATT layer (subsys/bluetooth/host/att.c) associates each in-flight ATT TX buffer with its owning channel via the static txmetadatastorage[] array (data->attchan = chan). When a buffer's last reference is dropped, its net-buf destroy callback defers the completion handling to the system workqueue (atttxdestroy -> atttxdestroyworkhandler -> attonsentcb -> btattsent), where btattsent dereferences the channel and its ATT context (sysslistget(&att->reqs)).

When a peer disconnects while an ATT PDU (a server notification/indication or any response) is still in flight in the controller TX path, L2CAP tears the channel down in l2capchandel(): it runs the disconnected callback and then the released callback (btattreleased), which frees the channel slab slot. Because the in-flight buffer is held by the connection TX path rather than the channel's own queue, its deferred destroy work can run after the channel has been freed. The attonsentcb guard intended to drop the stale callback itself dereferences meta->attchan, which is now a dangling pointer into a freed (and possibly reused) slab slot.

A remote peer with an ATT connection can drive this by disconnecting during routine ATT traffic; no pairing or user interaction is required to reach the ATT bearer. The result is a use-after-free read/write of freed channel memory, reliably crashing the Bluetooth host (denial of service) and, because the channel slab slot may be reused, potentially corrupting live memory.

The fix makes btattreleased() NULL the attchan field of every txmetadatastorage[] entry still referencing the channel before freeing it, so the deferred guard observes a NULL pointer and drops the callback. Teardown and the destroy work both run on the cooperative system workqueue, so the array update is serialized and needs no lock.