CVE-2026-74534 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: fix refcounting of iso_conn
iso_conn_del() and iso_chan_del() have a race that results to double-put of iso_conn:
[Task hdev->workqueue] [Task 2]
iso_conn_del iso_chan_del iso_conn_hold_unless_zero iso_conn_lock iso_conn_lock conn->sk = NULL iso_conn_unlock sk = iso_sock_hold(conn) <---------´ if (!sk) iso_conn_put iso_conn_put iso_conn_put /* UAF */
The extra put for !sk in iso_conn_del() is currently required since failing iso_chan_add() may leave iso_conn not associated with any sk.
Fix by having iso_pi(sk)->conn own refcount when non-NULL, so iso_conn_del does not need to put it. Adjust the iso_conn_add() refcounting so that conn is put if it does not get associated with an sk.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability exists within the Linux kernel's Bluetooth implementation specifically in the ISO (Individual Sound Organization) subsystem where improper reference counting leads to a use-after-free condition. The flaw occurs during concurrent execution of iso_conn_del() and iso_chan_del() functions which operate on the same iso_conn structure, creating a race condition that results in double invocation of the reference counter decrement operation. The vulnerability manifests when the iso_conn structure is released twice, potentially causing memory corruption or system instability.
The technical root cause stems from improper management of reference counts for iso_conn objects during Bluetooth connection lifecycle operations. When iso_chan_del() executes and subsequently calls iso_conn_hold_unless_zero(), followed by iso_sock_hold(conn) which returns NULL, the code path leads to an incorrect double-put operation on the same iso_conn structure. This race condition occurs because iso_conn_del() is unaware that the iso_conn object may already be in the process of being freed by another concurrent thread executing iso_chan_del(). The specific sequence involves iso_conn_lock operations followed by conditional checks that result in the same reference counter being decremented twice.
From a cybersecurity perspective, this vulnerability represents a critical memory safety issue that could be exploited to achieve arbitrary code execution or denial of service conditions. The use-after-free condition allows an attacker to potentially manipulate freed memory structures or cause system crashes through careful timing of concurrent operations. This type of vulnerability aligns with CWE-416 which specifically addresses Use After Free conditions, and can be categorized under ATT&CK technique T1059.007 for command and scripting interpreter. The issue affects the kernel's Bluetooth subsystem and could potentially be leveraged by malicious actors to compromise system integrity or availability.
The fix implemented modifies the reference counting mechanism by establishing that iso_pi(sk)->conn owns the reference count when non-NULL, eliminating the need for iso_conn_del() to perform its own put operation. This change requires adjusting iso_conn_add() to properly release the connection object if it fails to associate with a socket structure. The solution ensures proper ownership semantics where only one reference counting path manages the lifecycle of the iso_conn structure, preventing concurrent threads from attempting to free the same memory location. This approach follows established kernel security practices for managing shared resources and prevents race conditions that could lead to memory corruption or system instability.
The operational impact of this vulnerability extends beyond simple memory safety concerns as it affects Bluetooth functionality reliability across Linux systems. Systems utilizing Bluetooth ISO connections may experience unexpected crashes, data corruption, or potential privilege escalation if exploited by malicious actors. The race condition makes the vulnerability particularly challenging to reproduce consistently in controlled environments but highly dangerous when triggered during normal system operation. Organizations should prioritize patching this vulnerability through kernel updates, as it represents a fundamental flaw in the kernel's memory management for Bluetooth protocols that could be exploited to compromise entire systems or enable persistent access to networked devices.