CVE-2026-99011

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.