CVE-2026-90253: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: free the mesh send cancel command when it is cancelled
meshsendcancel() queues the pending command with a NULL destroy callback, so it is only freed if sendcancel() runs. A cancelled entry is leaked, as hcicmdsynccancelentry() does not release entry->data when there is no destroy callback, and hcicmdsyncclear() cancels every pending entry when the controller is unregistered. Nothing else reclaims it either: mgmtpendingnew() does not put the command on hdev->mgmtpending.
The leak also pins the socket reference taken by mgmtpendingnew(), so the mgmt socket is never released.
Free the command from a destroy callback.
Affected Software
Event History
Frequently Asked Questions
What conditions trigger the resource leak?
The leak occurs when a mesh send cancel command is queued and then cancelled, including when pending commands are cancelled as the Bluetooth controller is unregistered. The queued command has no destroy callback, so its data is not released during cancellation.
What is the practical impact of the leaked command?
In addition to leaking the command data, the issue retains the socket reference acquired by mgmt_pending_new(). As a result, the affected MGMT socket is never released.
What should be done to remediate the issue?
Apply a Linux kernel update containing the fix referenced by the listed stable kernel commits. The fix frees the command through a destroy callback when the pending command is cancelled.