CVE-2026-64404: Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: avoid NULL deref of conn in isoconnbigsync()
isoconnbigsync() drops the socket lock to call hcigetroute() and then re-acquires it, but dereferences isopi(sk)->conn->hcon afterwards without re-checking that conn is still valid.
While the lock is dropped, the connection can be torn down under the same socket lock: isodisconncfm() -> isoconndel() -> isochandel() sets isopi(sk)->conn to NULL (and the broadcast teardown path can also clear conn->hcon on its own). When isoconnbigsync() re-acquires the lock and reads conn->hcon, conn may be NULL, causing a NULL pointer dereference (hcon is the first member of struct isoconn).
This path is reached from isosockrecvmsg() for a PA-sync broadcast sink socket (BTSKDEFERSETUP | BTSKPASYNC), so the dropped-lock window can race with connection teardown driven by controller events.
Re-validate isopi(sk)->conn and its hcon after re-acquiring the socket lock and bail out if the connection went away, as already done in the sibling isosockrebindbc().
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems are exposed when they use the Linux kernel Bluetooth ISO path with a PA-sync broadcast sink socket configured with BT_SK_DEFER_SETUP and BT_SK_PA_SYNC. The vulnerable path is reached through iso_sock_recvmsg().
What conditions are required to trigger the crash?
An attacker or triggering condition needs a race between iso_conn_big_sync() dropping the socket lock to call hci_get_route() and connection teardown driven by controller events. The connection must be removed or have its hcon cleared before the socket lock is re-acquired.
What is the impact of successful exploitation?
The race can cause a NULL pointer dereference when the code accesses conn->hcon after the connection has been torn down. The supplied CVSS vector rates the impact as high availability impact, with no confidentiality or integrity impact.
How is the issue fixed?
The fix re-validates iso_pi(sk)->conn and its hcon after iso_conn_big_sync() re-acquires the socket lock, and exits if the connection is no longer present. This prevents dereferencing a NULL connection pointer.