Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessEstablish SCO link over Bluetooth
-
DeliveryStream SCO data during connection teardown
-
ExploitWin race on hcon->sco_data pointer
-
ExecutionTrigger kernel use-after-free
-
ImpactCrash or corrupt kernel memory
Vulnerability Assessment
| Exploitation Conditions | Exploitation requires Bluetooth-adjacent access (AV:A) to a host with the Bluetooth stack active and an SCO/eSCO audio link in use - the vulnerable path is sco_recv_scodata() in hci_rx_work, which only runs for SCO connections. The specific trigger is a concurrency race: the attacker must cause the RX path to read hcon->sco_data at the same moment the last sco_conn reference is dropped in sco_conn_free() (which cleared the pointer without hdev->lock), per the commit. Limiting factors that reduce realistic risk: the adjacency requirement (not internet-reachable), the need for an established SCO session (reflected as UI:R), and the narrow, timing-dependent race window (AC:H) that makes reliable exploitation difficult rather than a deterministic single-shot trigger. Hosts with Bluetooth disabled or no SCO audio usage are not reachable. |
| Impact | This is a genuine kernel use-after-free, but the real-world risk signals point to a moderate rather than urgent threat. The CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H, base 7.1) is internally consistent with the commit text: AV:A reflects the Bluetooth-adjacent attack surface, and AC:H is justified by actual evidence - the flaw is a race between sco_recv_scodata() upgrading the weak hcon->sco_data back-pointer under hdev->lock and sco_conn_free() clearing that pointer without the lock, so the attacker must win a narrow timing window rather than exploit a deterministic condition. EPSS is low (0.21%, 10th percentile), the CVE is NOT in CISA KEV, and no public exploit or PoC reference is present (the only links are the stable-tree fix commits), so there is no evidence of exploitation or weaponization. These signals agree: a locally/adjacently reachable, race-dependent kernel bug that is hard to drive remotely. The vuln.today decision label is 'this_week', consistent with 'patch on a normal cadence' rather than emergency. Note a tension worth verifying: the input Tags label this 'Information Disclosure', yet the commit and KASAN trace describe a slab use-after-free write, which is memory corruption (DoS/possible privilege escalation) rather than a pure read primitive - treat the disclosure framing with caution. |
| Exploit ScenarioDerived | An attacker within Bluetooth range establishes or induces an SCO (audio) link to a target Linux host and then forces connection teardown while SCO data frames are still arriving, racing the RX worker against the freeing of the sco_conn object. If the race is won, hci_rx_work touches hcon->sco_data after the backing sco_conn has been freed, producing a kernel use-after-free that most reliably crashes the host (DoS) and could theoretically be developed toward memory corruption. No public exploit or PoC code has been identified; AC:H and the adjacent vector make reliable exploitation difficult. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 24, 2026
Use-after-free in the Linux kernel Bluetooth SCO receive path can let an unauthenticated Bluetooth-adjacent attacker corrupt or disclose kernel memory while an SCO/eSCO audio link is active. The flaw is a race between sco_recv_scodata() reading hcon->sco_data and sco_conn_free() clearing that pointer without hdev->lock, so reliable exploitation is timing-dependent and requires user interaction to establish the SCO session. Vendor patches are listed for Linux 6.18.57, 7.2.11, and 7.3, EPSS is 0.21% (10th percentile), and no public exploit has been identified at time of analysis.
RemediationAI
Vendor-released patch: Linux 6.18.57, 7.2.11, and 7.3 per EUVD; apply the corresponding stable commits b108ea7ebba147465f4158d8133f0e8f013762ed, 8a98d58f6cfe70d51138cd9ce894e72671d95f8a, and 816fb1590a4c8cf8d05cd076057616be02e276f0 from git.kernel.org or update to a fixed kernel package from the distribution. The advisory reference is https://nvd.nist.gov/vuln/detail/CVE-2026-99011. For systems that cannot be updated, disabling Bluetooth or ensuring no SCO/eSCO audio link is in use removes the reachable path, at the cost of Bluetooth functionality; this is not a complete substitute for applying the kernel fix.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Linux kernel Bluetooth SCO/eSCO audio uses hci_conn objects plus a separate reference-counted sco_conn structure. The RX work item sco_recv_scodata() runs under hdev->lock, looks up hcon->sco_data, and tried to upgrade that weak pointer with kref_get_unless_zero(), but sco_conn_free() cleared hcon->sco_data without hdev->lock, so the pointer could be read while the sco_conn was concurrently freed; kref_get_unless_zero() only rejects a zero refcount and cannot protect memory that has already been freed. The fix gives hcon->sco_data its own reference, clears and drops it only from sco_conn_del() under hdev->lock, and moves hci_conn ownership to the socket so closing a connected SCO socket still tears down the link. The supplied CPE identifies linux:linux; CWE is not provided, but the root-cause class is a use-after-free/refcount-lifetime race, consistent with the KASAN report showing a write in sco_conn_hold_unless_zero from hci_rx_work. The CVSS vector AV:A/AC:H/PR:N/UI:R matches Bluetooth-adjacent access, a timing-dependent race, and user interaction required for SCO session establishment.
Know when Bluetooth gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
AV:A for Bluetooth adjacency; AC:H because the commit describes a timing race on hcon->sco_data; PR:N but UI:R since an active SCO link is required; kernel UAF yields full C/I/A.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()
sco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a strong reference under hdev->lock:
hci_dev_lock(hdev); hcon = hci_conn_hash_lookup_handle(hdev, handle); ... conn = sco_conn_hold_unless_zero(hcon->sco_data); hci_dev_unlock(hdev);
but the pointer is cleared from the other side without that lock. When the last sco_conn reference is dropped, sco_conn_free() ran
conn->hcon->sco_data = NULL;
with no hdev->lock held, so the RX path could read hcon->sco_data and call kref_get_unless_zero() on an sco_conn that was concurrently freed:
BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hci_rx_work Call Trace: sco_conn_hold_unless_zero+0xbe/0x160 sco_recv_scodata+0x13f/0x490 hci_rx_work+0x3af/0x730
kref_get_unless_zero() only guards against a zero refcount, not against the backing memory already being freed.
Give hcon->sco_data an actual reference on the sco_conn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from sco_conn_del(), which runs under hdev->lock (its callers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in sco_recv_scodata() also takes hdev->lock, so the store and the read are now serialised: the RX path either observes NULL or a reference that is guaranteed to stay valid until it drops its own.
sco_conn_add() no longer hands its kref_init() reference to the caller as the connection's only reference; that initial reference is the one owned by hcon->sco_data, and callers get their own via sco_conn_hold().
Because the sco_conn can now outlive the socket (the association keeps it alive until the link goes down), the hci_conn can no longer be dropped from sco_conn_free() without regressing socket close: closing a connected SCO socket must still tear the link down. Move hci_conn ownership to the socket instead: __sco_chan_add() takes an hci_conn reference and it is released from sco_chan_del() and sco_sock_destruct(), exactly once. The sco_conn no longer owns an hci_conn reference, so sco_conn_add() stops consuming one and sco_connect() drops the hci_connect_sco() reference on every path; sco_connect_cfm() no longer needs its hci_conn_hold() dance.
Executive ViewAI
The Linux kernel Bluetooth SCO receive path contains a high-severity memory corruption flaw (CVE-2026-99011) that could allow an attacker within Bluetooth range to read or alter kernel memory. While exploitation requires a timing-dependent race and an active SCO audio link, the broad deployment of Linux in servers, endpoints, and IoT devices means any compromise could lead to data leakage or system instability, undermining trust in our infrastructure.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware
CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.
Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiat
Heap OOB write in Android Bluetooth driver via incorrect bounds check.
A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an att
Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may
Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attac
A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the ker
A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data poi
Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock
Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into usersp
Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by rac
EUVD-2026-108805
GHSA-jp44-3rrh-3mww
NVD
CVE.org
EPSS
Exploit-DB