Look up another CVE · open CVE-2026-89774 in the interactive tracker
CVE-2026-89774
Bluetooth: SCO: hold sk properly in sco_conn_ready
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem net/bluetooth. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89774 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.180-1 | Update the kernel and reboot. Fixed in 6.1.180-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
sk deref in sco_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk and parent sk is currently accessed without either, and without checking parent->sk_state: [Task 1] [Task 2] sco_sock_release sco_conn_ready sk = conn->sk lock_sock(sk) conn->sk = NULL lock_sock(sk) release_sock(sk) sco_sock_kill(sk) UAF on sk deref and similarly for access to sco_get_sock_listen() return value. Fix possible UAF by holding sk refcount in sco_conn_ready() and making sco_get_sock_listen() increase refcount. Also recheck after lock_sock that the socket is still valid. Adjust conn->sk locking so it's protected also by lock_sock() of the associated socket if any.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/bluetooth/sco.c
- What this is
- BLUETOOTH SUBSYSTEMMAINTAINERS section matched on net/bluetooth/ · linux-bluetooth@vger.kernel.org · Supported
- Kernel module
- bluetooth
Check it on the machine
grep -wE 'CONFIG_BT|CONFIG_BT_BREDR' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w bluetoothPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixie, forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_BT, CONFIG_BT_BREDR
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 8.8 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.40%, higher than 33.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/bluetooth
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15 | 5.15.212 | 50aae396dc30 |
| 5.15 | 6.1.178 | 6e3840578aaa |
| 5.15 | 6.6.145 | d141d9b769bc |
| 5.15 | 6.12.97 | 73cb063f5ec6 |
| 5.15 | 6.18.40 | 7199c78c3a3e |
| 5.15 | 7.1 | 4e37f6452d58 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- sco_conn_ready runs from sco_connect_cfm via hci_connect_cfm on HCI Connection Complete, Synchronous Connection Complete, and deferred Connection Request for SCO/eSCO, driven by an in-range Bluetooth peer. Kernel CNA guidance classifies Bluetooth as Adjacent.
- AC:LAttack complexity, low
- This is a use-after-free race between sco_conn_ready and sco_sock_release/sco_sock_kill. An attacker who times HCI SCO completion against socket close (rapid peer establish/teardown or concurrent connect/close) controls both sides and can retry until the window is hit; CONFIG_BT_BREDR defaults to y.
- PR:NPrivileges required, none
- Incoming SCO is accepted when any listen socket exists (typical HFP/audio daemons on phones) with no Linux credentials required of the peer. sco_sock_create has no capability check, and listener close can occur from automatic bluetoothd/PipeWire teardown during connection setup.
- UI:NUser interaction, none
- No victim action is required at exploit time. OS Bluetooth audio stacks keep SCO listeners and manage sockets during normal headset, hands-free, and automotive operation while peer-initiated SCO/eSCO traffic is processed.
- S:UScope, unchanged
- The use-after-free corrupts in-kernel Bluetooth socket memory and can enable privilege escalation within the same host kernel security authority. It does not cross a VM, container, or IOMMU boundary.
- C:HConfidentiality impact, high
- Use-after-free of struct sock after sco_sock_kill lets an attacker reclaim the freed slab object and read kernel memory through subsequent sock operations, which per CNA guidance is High confidentiality impact.
- I:HIntegrity impact, high
- sco_conn_ready writes sk->sk_state and makes an indirect call through sk->sk_state_change on the freed sock, a standard kernel heap UAF primitive for arbitrary write and control-flow hijack, scored High per UAF guidance.
- A:HAvailability impact, high
- lock_sock and subsequent sk field access on a freed socket cause a kernel oops or panic. Per CNA guidance any use-after-free is High availability impact even before full exploitation.