Description

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 MGMT_OP_PAIR_DEVICE command by walking hdev->mgmt_pending. The lookup returned a command that was still linked on the shared pending list, without keeping mgmt_pending_lock held for the later dereference and removal. A concurrent MGMT_OP_CANCEL_PAIR_DEVICE request can remove and free the same pending command before the callback uses it. The reverse race is also possible when cancel_pair_device() gets a command from pending_find() and a callback removes it before the cancel path dereferences it. This can lead to a use-after-free and a second list_del(). Make the pairing lookup helpers transfer ownership of the pending command by removing it from hdev->mgmt_pending while holding mgmt_pending_lock. 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 hci_conn reference in cancel_pair_device() because the command completion drops the reference stored in the pending command.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:56.063Z",
  "pubdate": "2026-08-15T13:17:56.063Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel Bluetooth subsystem, specifically within the mgmt interface handling of pairing command cancellations.\nThe vulnerability is classified as a Use-After-Free (UAF) and a double list deletion flaw, affecting the Linux kernel Bluetooth management implementation.\nSuccessful exploitation of this flaw can lead to local denial of service, memory corruption, and potentially arbitrary code execution within kernel space.\nThe affected system component is the mgmt command handling routines, specifically MGMT_OP_PAIR_DEVICE and MGMT_OP_CANCEL_PAIR_DEVICE.\nAn attacker with local access and the capability to execute Bluetooth management commands can trigger the race condition.\nThe vulnerability arises due to inadequate locking semantics and synchronization between asynchronous pairing completion callbacks and command cancellation paths when referencing pending commands on the hdev->mgmt_pending list.",
  "technicalDetails": "The root cause of the vulnerability stems from race conditions involving concurrent execution of pairing completion callbacks, authentication failure callbacks, and the MGMT_OP_CANCEL_PAIR_DEVICE request handler within the Linux kernel Bluetooth subsystem.\nVulnerable functions include the pairing lookup helpers which previously searched for pending MGMT_OP_PAIR_DEVICE commands on the hdev->mgmt_pending list by walking the list without retaining the mgmt_pending_lock during subsequent dereference and removal operations.\nDuring a pairing operation, if a completion or authentication failure callback looks up a pending command, a concurrent MGMT_OP_CANCEL_PAIR_DEVICE request handled by cancel_pair_device() can remove and free the exact same pending command before the callback completes its execution and dereferences it.\nConversely, the reverse race condition is also possible where the cancel path retrieves a command via pending_find() and an asynchronous callback removes and frees it before the cancel path performs its operations.\nThis lack of atomic ownership transfer leads directly to a use-after-free condition and a hazardous second list_del() execution, resulting in kernel memory corruption.\nThe attack flow requires an actor to trigger a pairing operation via MGMT_OP_PAIR_DEVICE and immediately issue a concurrent MGMT_OP_CANCEL_PAIR_DEVICE request or induce conditions that trigger rapid authentication failure callbacks simultaneously with cancellation attempts.\nBecause the command completion path drops the reference stored in the pending command, failure to secure proper reference counting and locking results in premature memory deallocation while other execution contexts still hold pointers to the structure.\nPrerequisites for exploitation include local execution capability interacting with the Bluetooth management socket interface, with no specialized remote network exposure required, though local unprivileged or privileged access to the AF_BLUETOOTH socket interface is utilized to send management commands."
}