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

Bluetooth: mgmt: fix UAF in pair command cancellation

The pairing completion and authentication failure callbacks look up the pending MGMTOPPAIRDEVICE command by walking hdev->mgmtpending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmtpendinglock held for the later dereference and removal.

A concurrent MGMTOPCANCELPAIRDEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancelpairdevice() gets a command from pendingfind() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second listdel().

Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmtpending while holding mgmtpendinglock. The callbacks and cancel path then complete the command and free it directly, so racing paths cannot find or free the same command again. Take a temporary hciconn reference in cancelpairdevice() because the command completion drops the reference stored in the pending command.