Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: hold sk properly in iso_conn_ready sk deref in iso_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk is currently accessed without either: [Task 1] [Task 2] iso_sock_release iso_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) iso_sock_kill(sk) UAF on sk deref Fix possible UAF by holding sk refcount in iso_conn_ready(). Also recheck after lock_sock that the socket is still valid. Adjust locking so conn->sk is cleared only under lock_sock.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-15T13:17:59.040Z",
  "pubdate": "2026-08-15T13:17:59.040Z",
  "executiveSummary": "A use-after-free vulnerability exists in the Linux kernel Bluetooth subsystem, specifically within the isochronous (ISO) connection handling functions. The vulnerability arises due to a race condition between connection readiness processing and socket release routines, where the socket pointer (conn->sk) is dereferenced without holding the necessary reference count or lock.\nIf successfully exploited, an unauthorized local attacker could trigger memory corruption, leading to a denial of service (kernel panic) or potentially arbitrary code execution within the kernel context. The vulnerability impacts systems running the Linux kernel utilizing Bluetooth ISO sockets.\nExploitation requires local access and the ability to execute code that interacts with the Bluetooth subsystem, specifically orchestrating a concurrent socket release while iso_conn_ready is executing. The risk implication is high due to the potential for kernel-level memory corruption and privilege escalation.",
  "technicalDetails": "The root cause of the vulnerability is a concurrency flaw involving socket lifecycle management in the Linux kernel Bluetooth ISO implementation. Specifically, in the iso_conn_ready function, the socket pointer (sk) derived from conn->sk is accessed without holding the appropriate conn->lock or incrementing the socket reference count.\nDuring a race condition, Task 1 executes iso_conn_ready and reads sk = conn->sk. Concurrently, Task 2 executes iso_sock_release, acquiring the socket lock via lock_sock(sk), setting conn->sk = NULL, releasing the lock, and calling iso_sock_kill(sk) to terminate the socket. Subsequently, Task 1 attempts to call lock_sock(sk) on the now-freed or invalidated socket memory, resulting in a use-after-free (UAF) condition during the dereference.\nThe vulnerable component is the Bluetooth ISO socket connection handler, specifically the iso_conn_ready and iso_sock_release functions. The attack flow involves timing socket closure operations to coincide with incoming connection readiness callbacks, exploiting the lack of synchronization and reference counting around conn->sk.\nAuthentication and privilege requirements are minimal in terms of kernel privileges if local execution is permitted, though standard local user capabilities to open Bluetooth sockets are required. Network exposure depends on the availability of the Bluetooth stack, but the race condition itself is typically triggered via local socket system calls and asynchronous event handling.\nThe impact of successful exploitation includes kernel crashes, denial of service, and unpredictable kernel memory corruption which could potentially be leveraged for local privilege escalation."
}