CVE-2026-64404 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()
iso_conn_big_sync() drops the socket lock to call hci_get_route() and then re-acquires it, but dereferences iso_pi(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: iso_disconn_cfm() -> iso_conn_del() -> iso_chan_del() sets iso_pi(sk)->conn to NULL (and the broadcast teardown path can also clear conn->hcon on its own). When iso_conn_big_sync() re-acquires the lock and reads conn->hcon, conn may be NULL, causing a NULL pointer dereference (hcon is the first member of struct iso_conn).
This path is reached from iso_sock_recvmsg() for a PA-sync broadcast sink socket (BT_SK_DEFER_SETUP | BT_SK_PA_SYNC), so the dropped-lock window can race with connection teardown driven by controller events.
Re-validate iso_pi(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 iso_sock_rebind_bc().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
This vulnerability exists in the linux kernel's bluetooth implementation within the iso_conn_big_sync() function where a race condition can lead to a null pointer dereference. The issue occurs during the processing of broadcast sink sockets with pa-sync functionality, specifically when handling the BT_SK_DEFER_SETUP and BT_SK_PA_SYNC socket flags. The function drops the socket lock to call hci_get_route() which allows other kernel threads to execute and potentially tear down the connection while the lock is released. This race condition creates a scenario where iso_disconn_cfm() followed by iso_conn_del() and iso_chan_del() can set iso_pi(sk)->conn to NULL, effectively clearing the connection structure that was previously valid.
The technical flaw manifests when the function re-acquires the socket lock and attempts to dereference iso_pi(sk)->conn->hcon without validating that conn is still a valid pointer. Since conn is set to NULL by the connection teardown process during the dropped-lock window, accessing conn->hcon results in a null pointer dereference. The struct iso_conn has hcon as its first member making this access particularly dangerous as it directly accesses memory at offset zero of a null pointer. This particular vulnerability falls under CWE-476 which describes NULL Pointer Dereference, and represents a classic race condition scenario where shared data structures are accessed without proper re-validation after lock release.
The operational impact of this vulnerability is significant as it can cause kernel crashes leading to system instability and potential denial of service conditions. Attackers could potentially exploit this by creating broadcast sink sockets with pa-sync functionality and then triggering the race condition through specific sequence of events involving connection teardown. The vulnerability affects systems running linux kernels where bluetooth iso connections are used, particularly those handling broadcast audio streaming or similar time-sensitive applications that rely on pa-sync functionality. This issue represents a critical kernel-level security flaw that could be leveraged to crash system processes or potentially escalate privileges depending on the broader context of how the kernel handles these race conditions.
The recommended mitigation strategy involves implementing proper validation checks after re-acquiring the socket lock, specifically checking that iso_pi(sk)->conn is still valid before attempting to access conn->hcon. The fix pattern already exists in the sibling function iso_sock_rebind_bc() which implements the same validation logic. This approach ensures that if a connection has been torn down while the lock was dropped, the function properly bails out rather than proceeding with invalid memory accesses. The solution follows established security practices for concurrent programming where shared resources must be re-validated after acquiring locks that were previously released, preventing the classic race condition pattern that leads to null pointer dereferences. This vulnerability demonstrates the importance of careful lock management in kernel code and aligns with ATT&CK technique T1068 which covers privilege escalation through kernel exploits, though this particular case primarily results in denial of service rather than privilege escalation.