CVE-2026-80683

HIGHPre-NVD 8.88.8
EchelonGraph scoreHIGH confidence

Score 8.8 from GitHub Security Advisory (severity: HIGH) published 2026-08-28. a secondary CVSS source baseline 8.8; sources differ by 0.0.

Triggered by: GitHub Security Advisory CVSS
Sources: epss, ghsa, secondary
Trending — 5 sources updated this week
8.8EG
EchelonGraph verdictPlan a fixSerious severity, but no confirmed exploitation yet.
  • High severity, but no confirmed exploitation yet
CISA-KEV: Not listedEPSS PROB: 0%CVSS: 8.8Exploit: None knownExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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

Bluetooth: SCO: give the socket its own sco_conn reference

sco_conn_del() drops a reference it does not own. It takes one transient reference via sco_conn_hold_unless_zero() and releases it with the sco_conn_put() that follows sco_sock_hold(); the additional put in the !sk branch releases a second one:

conn = sco_conn_hold_unless_zero(conn); ... sk = sco_sock_hold(conn); sco_conn_unlock(conn); sco_conn_put(conn);

if (!sk) { sco_conn_put(conn); return; }

When close() races the controller's Disconnection Complete, sco_chan_del() clears conn->sk and drops the socket's reference while sco_conn_del() is running. sco_conn_del() then sees sk == NULL, its own put drops the count to zero and frees the conn, and the second put writes to the freed kref:

BUG: KASAN: slab-use-after-free in sco_conn_put.part.0+0x1a/0x190 Write of size 4 at addr ffff8881099dec74 by task kworker/u17:3/413 Workqueue: hci1 hci_rx_work Call Trace: sco_conn_put.part.0+0x1a/0x190 hci_disconn_complete_evt+0x1ee/0x3e0 hci_event_packet+0x54a/0x650 hci_rx_work+0x321/0x3d0 Allocated by task 413: sco_conn_add+0x72/0x1a0 sco_connect_cfm+0x88/0x670 Freed by task 413: sco_conn_del.isra.0+0x3f/0xf0 hci_disconn_complete_evt+0x1ee/0x3e0 refcount_t: underflow; use-after-free.

The root cause is that the socket stores the connection without holding a reference of its own. __sco_chan_add() does:

sco_pi(sk)->conn = conn;

so the socket borrows whatever reference its caller happened to hold, and the callers paper over that with ad-hoc holds and puts. Give the socket a counted reference instead: __sco_chan_add() takes one and it is released together with the channel (sco_chan_del()) and in sco_sock_destruct(). With the socket holding its own reference, sco_conn_del() no longer needs the extra put and the redundant hold in sco_conn_ready() goes away.

Making the socket own its reference means the connection is now actually freed on the error paths of sco_connect() where it used to leak, which in turn runs sco_conn_free() and its hci_conn_drop(conn->hcon). To keep the hci_conn accounting balanced, make that ownership explicit as well: sco_conn_add() consumes one hci_conn reference and the sco_conn owns it for its lifetime. sco_connect() hands over the reference returned by hci_connect_sco() and no longer drops it on the error paths; sco_connect_cfm(), which is not given a reference, takes one with hci_conn_hold() before handing it to sco_conn_add() (and drops it again if the allocation fails); and the explicit hci_conn_hold() in sco_conn_ready() is removed. Every reference then has a single, clear owner.

CVSS v3
8.8
EG Score
8.8(high)
EG Risk
44(Track)
EG Risk 44/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity88% × 45%
Exploitation0% × 40%
Automatability30% × 15%
Action: Routine — remediate on your standard cadence.
EPSS PROB
0%
EPSS %ILE
14%
KEV
Not listed

Published

August 28, 2026

Last Modified

August 29, 2026

Advisory Details (3)

Auto-updated Aug 29, 2026
No patch confirmed yet.
generic

Bluetooth: SCO: give the socket its own sco_conn reference - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/abd93c85c8667add738ee82aeab95dd9fc8265a2
generic

Bluetooth: SCO: give the socket its own sco_conn reference - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/8fe627192fa5da7157f9a48608f13c04b6373e43
generic

Bluetooth: SCO: give the socket its own sco_conn reference - kernel/git/stable/linux.git - Linux kernel stable tree

https://git.kernel.org/stable/c/a33bc07b4730b6cd5681ac77d18ae0de3e739690

Vendor Advisories for CVE-2026-80683(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Data Freshness Timeline

(refreshed 12× in last 7d / 12× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-08-30 01:22 UTCEPSS rescore
  2. 2026-08-29 19:09 UTCEG score recompute
  3. 2026-08-29 19:08 UTCGHSA enrichment
  4. 2026-08-29 07:26 UTCEG score recompute
  5. 2026-08-29 07:26 UTCGHSA enrichment
  6. 2026-08-29 06:36 UTCEG score recompute 8.80
  7. 2026-08-29 06:36 UTCGHSA enrichment
  8. 2026-08-29 06:33 UTCMITRE cvelistV5CVSS v3 → 8.8 · severity → HIGH
  9. 2026-08-28 21:42 UTCEPSS rescore
  10. 2026-08-28 08:20 UTCNVD update
  11. 2026-08-28 07:34 UTCEG score recompute
  12. 2026-08-28 07:32 UTCMITRE cvelistV5first tracked

Frequently asked(5)

What is CVE-2026-80683?
CVE-2026-80683 is a high vulnerability published on August 28, 2026. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: give the socket its own sco_conn reference scoconndel() drops a reference it does not own. It takes one transient reference via scoconnholdunlesszero() and releases it with the scoconnput() that follows…
When was CVE-2026-80683 disclosed?
CVE-2026-80683 was first published in the National Vulnerability Database on August 28, 2026, with the most recent update on August 29, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2026-80683 actively exploited?
CVE-2026-80683 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 0% probability of exploitation in the next 30 days, which ranks it in the top 85.7% of all scored CVEs.
What is the CVSS score of CVE-2026-80683?
CVE-2026-80683 has a CVSS v3 base score of 8.8 (NVD).
How do I remediate CVE-2026-80683?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2026-80683, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

Explore the affected products and dependency analysis for CVE-2026-80683

Explore →

Is Your Infrastructure Affected by CVE-2026-80683?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.