Bug 2536295 (CVE-2026-90255) - CVE-2026-90255 kernel: Bluetooth: hci_conn: fix the SCO setup context lifetime
Summary: CVE-2026-90255 kernel: Bluetooth: hci_conn: fix the SCO setup context lifetime
Keywords:
Status: NEW
Alias: CVE-2026-90255
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-17 17:16 UTC by OSIDB Bzimport
Modified: 2026-10-05 14:10 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-17 17:16:51 UTC
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_conn: fix the SCO setup context lifetime

hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so
the context is only freed if hci_enhanced_setup_sync() actually runs. An
entry that is cancelled instead is leaked, as
_hci_cmd_sync_cancel_entry() does not release entry->data when there is
no destroy callback, and hci_cmd_sync_clear() cancels every pending entry
when the controller is unregistered.

The context also stores a bare hci_conn pointer, so the connection can be
freed while the work is queued. The dequeue in hci_conn_del() does not
cover it either, as it matches on entry->data == conn and entry->data is
the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth:
hci_sync: hold conn in hci_connect_acl/le_sync() callbacks").

Hold the connection and release both from a destroy callback. The
submission failure path drops both, since hci_cmd_sync_submit() does not
call the destroy callback when it fails to queue.


Note You need to log in before you can comment on or make changes to this bug.