UBUNTU-CVE-2026-99011: Use After Free
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: serialise scoconn lifetime against scorecvscodata() scorecvscodata() upgrades the weak hcon->scodata back-pointer to a strong reference under hdev->lock: hcidevlock(hdev); hcon = hciconnhashlookuphandle(hdev, handle); ... conn = scoconnholdunlesszero(hcon->scodata); hcidevunlock(hdev); but the pointer is cleared from the other side without that lock. When the last scoconn reference is dropped, scoconnfree() ran conn->hcon->scodata = NULL; with no hdev->lock held, so the RX path could read hcon->scodata and call krefgetunlesszero() on an scoconn that was concurrently freed: BUG: KASAN: slab-use-after-free in scoconnholdunlesszero+0xbe/0x160 Write of size 4 by task kworker/u17:0 Workqueue: hci0 hcirxwork Call Trace: scoconnholdunlesszero+0xbe/0x160 scorecvscodata+0x13f/0x490 hcirxwork+0x3af/0x730 krefgetunlesszero() only guards against a zero refcount, not against the backing memory already being freed. Give hcon->scodata an actual reference on the scoconn it points to, so the object cannot be freed while the pointer is still installed, and only clear and drop it from scoconndel(), which runs under hdev->lock (its callers, scoconnectcfm() and scodisconncfm(), hold it). The reader in scorecvscodata() 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. scoconnadd() no longer hands its krefinit() reference to the caller as the connection's only reference; that initial reference is the one owned by hcon->scodata, and callers get their own via scoconnhold(). Because the scoconn can now outlive the socket (the association keeps it alive until the link goes down), the hciconn can no longer be dropped from scoconnfree() without regressing socket close: closing a connected SCO socket must still tear the link down. Move hciconn ownership to the socket instead: scochanadd() takes an hciconn reference and it is released from scochandel() and scosockdestruct(), exactly once. The scoconn no longer owns an hciconn reference, so scoconnadd() stops consuming one and scoconnect() drops the hciconnectsco() reference on every path; scoconnectcfm() no longer needs its hciconnhold() dance.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1019.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.19~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.18~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1~24.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.3.0-10.10 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.3.0-1004.5 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-raspito a version that resolves this vulnerability.Fixed in 7.3.0-1004.4 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.3.0-10.10.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.3.0-10.10.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-43.43 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1017.18 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1020.21 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1019.19 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1017.19 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1010.11 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1018.18 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-43.43.1
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The listed software includes ubuntu/linux, ubuntu/linux-gke, ubuntu/linux-hwe-edge, ubuntu/linux-azure-fde, ubuntu/linux-gcp, ubuntu/linux-azure, ubuntu/linux-realtime, and ubuntu/linux-riscv.
What access and conditions does exploitation require?
The severity vector indicates adjacent-network attack access, no privileges required, user interaction required, and high attack complexity. The vulnerable path is Bluetooth SCO receive handling, involving a race between SCO connection teardown and receipt of SCO data.
What is the potential impact if the race is triggered?
The flaw is a use-after-free involving an SCO connection object. The provided severity vector rates confidentiality, integrity, and availability impact as high.
How can this issue manifest on an affected system?
The described failure can produce a KASAN slab-use-after-free report in sco_conn_hold_unless_zero() during sco_recv_scodata(), processed by the Bluetooth HCI receive workqueue.