Skip to main content

Linux Kernel CVE-2025-68304

HIGH
2025-12-16 416baaa9-dc9f-4396-8d5f-8c081fb06d67
8.8
CVSS 3.1 · Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Gain Bluetooth radio proximity
  2. Delivery
    Establish/trigger L2CAP ACL connection
  3. Exploit
    Force concurrent connection teardown
  4. Execution
    Race RX handler against hci_conn_del
  5. Persist
    Dereference freed hci_conn (UAF)
  6. Impact
    Kernel crash / potential memory corruption

Vulnerability Assessment

Exploitation Conditions

Requires Bluetooth radio proximity (adjacent network, AV:A) to a target with an active or in-teardown Bluetooth/L2CAP connection, plus the ability to trigger connection teardown concurrently with incoming ACL data to win a use-after-free race in the RX path. Limiting factors: the target must have Bluetooth enabled and processing L2CAP ACL data; exploitation depends on winning a narrow timing window between l2cap_recv_acldata using hcon and a concurrent hci_conn_del freeing it, so it is not deterministic. No authentication is required (PR:N per the supplied vector), but physical/RF adjacency and successful race timing meaningfully constrain real-world exploitation.

Impact

Signals are mixed. The supplied CVSS 8.8 (AV:A/AC:L/PR:N/UI:N, C:H/I:H/A:H) reflects an adjacent, unauthenticated, high-impact flaw, but the AC:L rating is questionable: the vulnerability is a timing-dependent race (syzkaller reproduced it via concurrent tasks), which argues for AC:H - this is a discrepancy defenders should note. EPSS is very low (0.15%, 5th percentile), it is not in CISA KEV, and no public exploit is identified, indicating no observed exploitation. The vendor tag explicitly says 'Denial Of Service,' suggesting the realistic outcome is a kernel crash rather than reliable code execution, even though the input CVSS asserts full C/I/A impact. Net: this is a legitimate memory-safety bug worth patching in the normal kernel update cycle, but it is not an emergency - exploitation requires Bluetooth adjacency and winning a narrow race, and no weaponization is evident.

Exploit ScenarioDerived

An attacker within Bluetooth radio range establishes or manipulates an ACL/L2CAP connection to a target while concurrently forcing connection teardown (e.g., abrupt disconnect), racing the RX handler against hci_conn_del so the kernel dereferences a freed hci_conn and crashes. Given AV:A and the timing-sensitive nature (effectively AC:H), the attacker must be in proximity and repeatedly trigger the race; the syzkaller reproducer demonstrates the crash but no public weaponized exploit exists.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 30, 2026

Use-after-free in the Linux kernel Bluetooth HCI core (hci_core) lets an attacker within Bluetooth range trigger a race between the ACL data RX path (l2cap_recv_acldata) and connection teardown (hci_abort_conn_sync/hci_conn_del), causing the RX handler to dereference a freed hci_conn structure. A syzkaller-reproduced crash confirms the flaw, which primarily manifests as denial of service though memory corruption cannot be excluded; there is no public exploit identified at time of analysis and it is not listed in CISA KEV. The issue is resolved upstream by moving the hci_conn lookup into the protocol receive handlers under a single RCU/lock-protected critical section.

RemediationAI

Upstream fix available (PR/commit); released patched version not independently confirmed - apply the stable kernel commits 79a2d4678ba90bdba577dc3af88cc900d6dcd5ee and ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93, or the corresponding fixed kernel package from your distribution once released. Track your distro's security advisory for the tagged release that includes these commits, since exact fixed version numbers were not in the input. As a compensating control until patched, disable the Bluetooth stack where it is not needed (rmmod/blacklist the bluetooth and btusb modules, or 'systemctl disable --now bluetooth'), which fully removes the attack surface at the cost of losing Bluetooth functionality; where Bluetooth is required, minimize exposure by keeping the device non-discoverable and unpaired from untrusted peers to reduce the window for an adjacent attacker to drive the RX/teardown race.

Affected ProductsAI

The Linux kernel Bluetooth subsystem (hci_core / L2CAP ACL receive path) is affected. Exact vulnerable version ranges were not enumerated in the provided data; the flaw exists in kernels that carry the RCU conn_hash conversion (bf4c63252490b) and the deletion paths such as 5af1f84ed13a but lack the fix. The fix is published as two kernel.org stable commits: https://git.kernel.org/stable/c/79a2d4678ba90bdba577dc3af88cc900d6dcd5ee and https://git.kernel.org/stable/c/ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93. No CPE strings were provided, so precise affected/fixed version boundaries should be confirmed against your distribution's kernel changelog.

Affects your stack

Find out whether the stacks and servers you run are on an affected version.

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The affected subsystem is the Linux kernel Bluetooth stack, specifically hci_core.c and the L2CAP receive path. Connections are tracked in hdev->conn_hash, which was converted to RCU in commit bf4c63252490b. The legacy lock/lookup/unlock/use pattern on the packet RX path did not keep a stable reference to hci_conn across its use, so a concurrent deletion path (introduced in part by commit 5af1f84ed13a fixing a UAF on hci_abort_conn_sync) could free the hci_conn while the RX work still held a pointer to it and later read hcon->l2cap_data. This is a classic CWE-416 (Use After Free) rooted in a CWE-362 (concurrent execution / race condition) - the RX work runs on the ordered hdev->workqueue while deletions occur from other tasks outside that queue. No CWE was supplied in the input; these classes are inferred from the described mechanism.

Know when the next one hits your stack

  • 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

Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY 8.8 HIGH
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 7.5 HIGH

Bluetooth proximity gives AV:A; the flaw is a timing-dependent UAF race so AC:H; no auth needed (PR:N); kernel-level UAF plausibly enables full C/I/A impact though DoS is the confirmed effect.

3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:A/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat 5.5 MEDIUM

Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_core: lookup hci_conn on RX path on protocol side

The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.

Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible.

Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup.

syzkaller has reported a crash that appears to be this issue:

[Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)

Executive ViewAI

Why It Matters

A use-after-free vulnerability in Linux kernel Bluetooth connectivity (CVE-2025-68304, CVSS 8.8) can force devices within Bluetooth range to crash or become unresponsive, affecting organizational availability of Bluetooth-enabled systems including laptops, IoT devices, and mobile infrastructure. Without an available patch, this denial-of-service flaw presents immediate risk to uptime across multiple device categories. Leadership should prioritize patching readiness and interim availability controls.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) disable Bluetooth on systems where not operationally required; (2) restrict physical proximity of Bluetooth devices to critical systems; (3) implement enhanced kernel crash monitoring with automated recovery; (4) prioritize immediate patching upon availability from your Linux distribution vendor.

Threat Intelligence Overview

EPSS Score
0.1%
Top 95% exploitable
Prevalence
Ubiquitous
Linux kernel Bluetooth stack ships across countless Linux devices and distributions
Data Quality
4 sources
Confidence: Medium

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Controlled
Automatable· derived
No
Human Impact
High

Priority Score

44
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy