Read the docs
TI-2026-79804 Aliases CVE-2026-99011GHSA-jp44-3rrh-3mww

Use-after-free in Linux kernel Bluetooth SCO connection handling

Priority LOW 31Published · Updated

Key facts

Attack vector
Adjacent network
Privileges required
None
User interaction
Required
Attack complexity
High
Impact type
—
Confidentiality · integrity · availability
High · High · High
Fix status
Partial Red Hat: 4 without a fix

Attack profile from CVSS 3.1 · CNA. Fix status from CNA and Red Hat.

Summary

The Linux kernel from 6.13 is affected. The Bluetooth SCO code clears a connection pointer without holding the device lock, so the receive path can take a reference to an SCO connection that is already being freed. An adjacent attacker with no privileges can corrupt kernel memory, with high impact to confidentiality, integrity and availability, though the attack is complex and needs user interaction.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

Description from the CNA

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.

Why it matters now

EPSS 0.00225 13th percentileScored 2026-11-07
Fix Partial Linux (Linux): 6.18.57, 7.2.11, 7.3Red Hat: 4 without a fix

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
LinuxLinux6.13 and later6.18.57, 7.2.11, 7.3Patch availableCNA
  • Linux VendorLinux Affected 6.13 and later Fixed in 6.18.57, 7.2.11, 7.3 Patch available CNA

CPE names Threatist (inferred) · 1

Inferred from how NVD named this product before; not given by a source.

CPEVersionsRoleVendor
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*——Linux
  • cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* Versions — — ·Linux

Remediation

Upgrade the Linux kernel to 6.18.57, 7.2.11 or 7.3. Red Hat lists Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 9 and Red Hat OpenShift Container Platform 4 as affected with no fix available, and Red Hat Enterprise Linux 6 as affected with no fix planned.

Written with Claude Haiku 5.5 from the sources below · 2026-11-06

  • Fix · CNA Linux (Linux) Fixed in 6.18.57, 7.2.11, 7.3

Vendor assessments

Red Hat

Red Hat rating: Moderate. Red Hat's page for this CVE →

ProductStatusPlan or fix
Red Hat Enterprise Linux 10AffectedNo fix yet: Fix deferred
Red Hat Enterprise Linux 6AffectedNo fix planned: Out of support scope
Red Hat Enterprise Linux 9AffectedNo fix yet: Fix deferred
Red Hat OpenShift Container Platform 4AffectedNo fix yet: Fix deferred
Not affected: 4 products
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9
  • Red Hat OpenShift Container Platform 4

Timeline

  1. 2026-10-23 Threatist record created from CVE-2026-99011
  2. 2026-10-23 Alias added: GHSA-jp44-3rrh-3mww
  3. 2026-10-24 CVSS score added · CNA
  4. 2026-10-24 Priority changed: LOW → MEDIUM
  5. 2026-10-24 Priority changed: MEDIUM → LOW
  6. 2026-10-29 Affected versions changed · Red Hat
  7. 2026-10-29 CVSS score added · Red Hat

References

  • TI-2025-26358 tls: fix handling of zero-length records on the rx_list KEVCVSS 3.1CRITICAL 9.8
  • TI-2026-38352 netfilter: bridge: make ebt_snat ARP rewrite writable KEVCVSS 3.1HIGH 8.8
  • TI-2021-02452 Incorrect authorization in Ubuntu linux kernel KEVCVSS 3.1HIGH 8.8
  • TI-2013-05264 The (1) get_user and (2) put_user API functions in the Linux kernel before 3.5.5 on the… KEVCVSS 3.1HIGH 8.8
  • TI-2022-00125 Integer overflow in kernel KEVCVSS 3.1HIGH 8.4
  • TI-2013-01864 The perf_swevent_init function in kernel/events/core.c in the Linux kernel before 3.8.9… KEVCVSS 3.1HIGH 8.4
See all 21727 →

Sources