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

Bluetooth: mgmt: Dequeue pending mesh send sync entries on cancel

In send cancel(), pending mesh tx objects are removed from the hdev->mesh pending list and freed via mesh send complete(). However, if a mesh transmission was already queued onto hdev->cmd sync work list via mesh next(), the queued entry retains a raw pointer to mesh tx.

When hci cmd sync work later processes the entry, it attempts to execute mesh send sync and its destroy callback mesh send start complete using the already freed mesh tx pointer, leading to a use-after-free.

Fix this by invoking hci cmd sync dequeue() for mesh send sync on the target mesh tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh send complete() is called directly.

Additionally, ensure the transmission queue advances after cancellation or errors. In mesh send start complete(), call mesh next() on error unless err is -ECANCELED, because hci cmd sync dequeue() holds hdev->cmd sync work lock and calling mesh next() synchronously would deadlock. Instead, advance the queue in send cancel() once the lock is released and if no transmission is in progress.