Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix pending command UAF in EIR updates MGMT_OP_SET_LOCAL_NAME is handled asynchronously on powered controllers and can run set_name_sync(). When the controller is BR/EDR capable, set_name_sync() updates the local name and then rebuilds EIR data through eir_create(). The EIR builder walks hdev->uuids, but the UUID list can be changed and entries can be freed by MGMT_OP_ADD_UUID and MGMT_OP_REMOVE_UUID. pending_eir_or_class() is meant to serialize management commands that can change EIR or the class of device, but it did not include MGMT_OP_SET_LOCAL_NAME. In addition, it walked hdev->mgmt_pending without hdev->mgmt_pending_lock even though pending commands are added and removed under that mutex. A racing command completion can therefore remove and free a pending command while pending_eir_or_class() is still inspecting it, leading to a use-after-free in the pending-command list or allowing a local name update to rebuild EIR while UUID entries are being removed. Take hdev->mgmt_pending_lock while scanning hdev->mgmt_pending and treat MGMT_OP_SET_LOCAL_NAME as an EIR/class-affecting pending command on the powered asynchronous path. Check for a conflicting pending command before copying the new short name so a rejected SET_LOCAL_NAME request does not modify hdev->short_name.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-15T13:17:56.177Z",
  "pubdate": "2026-08-15T13:17:56.177Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel's Bluetooth subsystem management interface, specifically within Extended Inquiry Response (EIR) updates.\nThe vulnerability arises due to inadequate serialization of asynchronous management commands and a missing lock when inspecting the pending command list.\nAn attacker capable of executing local Bluetooth management operations can trigger a race condition between MGMT_OP_SET_LOCAL_NAME and commands that modify UUID entries, such as MGMT_OP_ADD_UUID and MGMT_OP_REMOVE_UUID.\nSuccessful exploitation of this flaw can lead to a use-after-free condition within the pending-command list, potentially resulting in kernel memory corruption, system crashes, or arbitrary code execution.\nThe issue affects systems running the Linux kernel where Bluetooth BR/EDR capabilities are enabled and asynchronous local name updates are processed.\nExploitation requires local access or execution capability on the host system to interact with the Bluetooth management socket interface.",
  "technicalDetails": "The vulnerability is located in the Linux kernel Bluetooth subsystem management implementation, specifically involving MGMT_OP_SET_LOCAL_NAME, MGMT_OP_ADD_UUID, and MGMT_OP_REMOVE_UUID.\nThe root cause stems from two distinct concurrency flaws: first, pending_eir_or_class() failed to serialize MGMT_OP_SET_LOCAL_NAME alongside other management commands that alter EIR data or the class of device; second, the function iterated over hdev->mgmt_pending without acquiring the required hdev->mgmt_pending_lock mutex.\nDuring asynchronous handling of MGMT_OP_SET_LOCAL_NAME on powered controllers, set_name_sync() is invoked. When the controller is BR/EDR capable, this function updates the local name and rebuilds EIR data via eir_create().\nThe EIR builder traverses hdev->uuids, but because synchronization was lacking, concurrent execution of MGMT_OP_ADD_UUID or MGMT_OP_REMOVE_UUID could modify or free UUID list entries while they were actively being read.\nFurthermore, a racing command completion could remove and free a pending command while pending_eir_or_class() was actively inspecting the hdev->mgmt_pending list.\nThis race condition directly causes a use-after-free vulnerability within the pending-command list and allows local name updates to rebuild EIR data while underlying UUID entries are simultaneously being removed.\nAn attacker can exploit this by rapidly issuing conflicting Bluetooth management commands to race the command completion handlers against the asynchronous EIR generation path.\nAs a secondary consequence of the flawed logic, the short name modification occurred before checking for conflicting pending commands, leading to potential state corruption in hdev->short_name when requests were rejected.\nThe issue requires local execution privileges to open a Bluetooth management socket and dispatch crafted management opcodes."
}