{"api_version":"1","generated_at":"2026-10-27T04:27:50+00:00","cve":"CVE-2026-99011","urls":{"html":"https://cve.report/CVE-2026-99011","api":"https://cve.report/api/cve/CVE-2026-99011.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-99011","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-99011"},"summary":{"title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()\n\nsco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a\nstrong reference under hdev->lock:\n\n    hci_dev_lock(hdev);\n    hcon = hci_conn_hash_lookup_handle(hdev, handle);\n    ...\n    conn = sco_conn_hold_unless_zero(hcon->sco_data);\n    hci_dev_unlock(hdev);\n\nbut the pointer is cleared from the other side without that lock. When\nthe last sco_conn reference is dropped, sco_conn_free() ran\n\n    conn->hcon->sco_data = NULL;\n\nwith no hdev->lock held, so the RX path could read hcon->sco_data and\ncall kref_get_unless_zero() on an sco_conn that was concurrently freed:\n\n    BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160\n    Write of size 4 by task kworker/u17:0\n    Workqueue: hci0 hci_rx_work\n    Call Trace:\n     sco_conn_hold_unless_zero+0xbe/0x160\n     sco_recv_scodata+0x13f/0x490\n     hci_rx_work+0x3af/0x730\n\nkref_get_unless_zero() only guards against a zero refcount, not against\nthe backing memory already being freed.\n\nGive hcon->sco_data an actual reference on the sco_conn it points to, so\nthe object cannot be freed while the pointer is still installed, and only\nclear and drop it from sco_conn_del(), which runs under hdev->lock (its\ncallers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in\nsco_recv_scodata() also takes hdev->lock, so the store and the read are\nnow serialised: the RX path either observes NULL or a reference that is\nguaranteed to stay valid until it drops its own.\n\nsco_conn_add() no longer hands its kref_init() reference to the caller as\nthe connection's only reference; that initial reference is the one owned\nby hcon->sco_data, and callers get their own via sco_conn_hold().\n\nBecause the sco_conn can now outlive the socket (the association keeps it\nalive until the link goes down), the hci_conn can no longer be dropped\nfrom sco_conn_free() without regressing socket close: closing a connected\nSCO socket must still tear the link down. Move hci_conn ownership to the\nsocket instead: __sco_chan_add() takes an hci_conn reference and it is\nreleased from sco_chan_del() and sco_sock_destruct(), exactly once. The\nsco_conn no longer owns an hci_conn reference, so sco_conn_add() stops\nconsuming one and sco_connect() drops the hci_connect_sco() reference on\nevery path; sco_connect_cfm() no longer needs its hci_conn_hold() dance.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-10-23 13:17:23","updated_at":"2026-10-24 14:16:52"},"problem_types":[],"metrics":[{"version":"3.1","source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","score":"7.1","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","baseScore":7.1,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"REQUIRED","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"DECLARED","score":"7.1","severity":"HIGH","vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","data":{"baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a","name":"https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0","name":"https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed","name":"https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-99011","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99011","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e6720779ae612a14ac4ba7fe4fd5b27d900d932c b108ea7ebba147465f4158d8133f0e8f013762ed git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e6720779ae612a14ac4ba7fe4fd5b27d900d932c 8a98d58f6cfe70d51138cd9ce894e72671d95f8a git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected e6720779ae612a14ac4ba7fe4fd5b27d900d932c 816fb1590a4c8cf8d05cd076057616be02e276f0 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.13","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.13 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.57 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2.11 7.2.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.3 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/bluetooth/sco.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"b108ea7ebba147465f4158d8133f0e8f013762ed","status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","versionType":"git"},{"lessThan":"8a98d58f6cfe70d51138cd9ce894e72671d95f8a","status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","versionType":"git"},{"lessThan":"816fb1590a4c8cf8d05cd076057616be02e276f0","status":"affected","version":"e6720779ae612a14ac4ba7fe4fd5b27d900d932c","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/bluetooth/sco.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.13"},{"lessThan":"6.13","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.57","versionType":"semver"},{"lessThanOrEqual":"7.2.*","status":"unaffected","version":"7.2.11","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.3","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.57","versionStartIncluding":"6.13","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2.11","versionStartIncluding":"6.13","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.3","versionStartIncluding":"6.13","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()\n\nsco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a\nstrong reference under hdev->lock:\n\n    hci_dev_lock(hdev);\n    hcon = hci_conn_hash_lookup_handle(hdev, handle);\n    ...\n    conn = sco_conn_hold_unless_zero(hcon->sco_data);\n    hci_dev_unlock(hdev);\n\nbut the pointer is cleared from the other side without that lock. When\nthe last sco_conn reference is dropped, sco_conn_free() ran\n\n    conn->hcon->sco_data = NULL;\n\nwith no hdev->lock held, so the RX path could read hcon->sco_data and\ncall kref_get_unless_zero() on an sco_conn that was concurrently freed:\n\n    BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160\n    Write of size 4 by task kworker/u17:0\n    Workqueue: hci0 hci_rx_work\n    Call Trace:\n     sco_conn_hold_unless_zero+0xbe/0x160\n     sco_recv_scodata+0x13f/0x490\n     hci_rx_work+0x3af/0x730\n\nkref_get_unless_zero() only guards against a zero refcount, not against\nthe backing memory already being freed.\n\nGive hcon->sco_data an actual reference on the sco_conn it points to, so\nthe object cannot be freed while the pointer is still installed, and only\nclear and drop it from sco_conn_del(), which runs under hdev->lock (its\ncallers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in\nsco_recv_scodata() also takes hdev->lock, so the store and the read are\nnow serialised: the RX path either observes NULL or a reference that is\nguaranteed to stay valid until it drops its own.\n\nsco_conn_add() no longer hands its kref_init() reference to the caller as\nthe connection's only reference; that initial reference is the one owned\nby hcon->sco_data, and callers get their own via sco_conn_hold().\n\nBecause the sco_conn can now outlive the socket (the association keeps it\nalive until the link goes down), the hci_conn can no longer be dropped\nfrom sco_conn_free() without regressing socket close: closing a connected\nSCO socket must still tear the link down. Move hci_conn ownership to the\nsocket instead: __sco_chan_add() takes an hci_conn reference and it is\nreleased from sco_chan_del() and sco_sock_destruct(), exactly once. The\nsco_conn no longer owns an hci_conn reference, so sco_conn_add() stops\nconsuming one and sco_connect() drops the hci_connect_sco() reference on\nevery path; sco_connect_cfm() no longer needs its hci_conn_hold() dance."}],"metrics":[{"cvssV3_1":{"baseScore":7.1,"baseSeverity":"HIGH","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","version":"3.1"},"scenarios":[{"lang":"en","value":"AV:A - An in-range peer's Bluetooth SCO/eSCO data enters as HCI_SCODATA_PKT through hci_recv_frame() → hci_rx_work() → hci_scodata_packet() → the patched sco_recv_scodata(). The radio-range transport makes the vector Adjacent.\nAC:H - Peer-induced Disconnection Complete runs on the same ordered HCI workqueue and calls sco_conn_del() under hdev->lock, so it cannot create this race. Exploitation must instead coincide with local close()/shutdown() freeing the sco_conn outside that lock, timing the peer cannot control.\nPR:N - hci_scodata_packet() and sco_recv_scodata() impose no peer credential or capability check once a SCO/eSCO handle exists. For inbound setup, sco_connect_ind() checks only for a listening SCO socket, not authentication.\nUI:R - The last reference must be dropped through victim-side sco_sock_release() or sco_sock_shutdown() while peer data is received. Because peer-driven sco_disconn_cfm() is serialized against receive processing, a separate victim socket teardown is required.\nS:U - The stale hcon->sco_data pointer corrupts a freed sco_conn inside the host Bluetooth kernel stack; it does not cross a VM, IOMMU, or other security-authority boundary.\nC:H - After sco_conn_hold_unless_zero() revives reclaimed storage, sco_recv_frame() reads the reused conn->sk pointer and socket state. Heap grooming can therefore turn the sco_conn UAF into kernel-memory disclosure.\nI:H - kref_get_unless_zero() performs a four-byte atomic increment in the freed sco_conn, followed on success by spinlock and kref operations on reclaimed storage. Reuse can convert these writes into kernel heap corruption and control-flow hijacking.\nA:H - The demonstrated stale reference causes a KASAN slab-use-after-free write in sco_conn_hold_unless_zero() from hci_rx_work; such corruption can produce an oops or kernel panic."}]}],"providerMetadata":{"dateUpdated":"2026-10-24T14:09:59.382Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/b108ea7ebba147465f4158d8133f0e8f013762ed"},{"url":"https://git.kernel.org/stable/c/8a98d58f6cfe70d51138cd9ce894e72671d95f8a"},{"url":"https://git.kernel.org/stable/c/816fb1590a4c8cf8d05cd076057616be02e276f0"}],"title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-99011","datePublished":"2026-10-23T12:20:36.460Z","dateReserved":"2026-09-25T10:25:14.385Z","dateUpdated":"2026-10-24T14:09:59.382Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-23 13:17:23","lastModifiedDate":"2026-10-24 14:16:52","problem_types":[],"metrics":{"cvssMetricV31":[{"source":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","baseScore":7.1,"baseSeverity":"HIGH","attackVector":"ADJACENT_NETWORK","attackComplexity":"HIGH","privilegesRequired":"NONE","userInteraction":"REQUIRED","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":1.2,"impactScore":5.9}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"99011","Ordinal":"1","Title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_sco","CVE":"CVE-2026-99011","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"99011","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()\n\nsco_recv_scodata() upgrades the weak hcon->sco_data back-pointer to a\nstrong reference under hdev->lock:\n\n    hci_dev_lock(hdev);\n    hcon = hci_conn_hash_lookup_handle(hdev, handle);\n    ...\n    conn = sco_conn_hold_unless_zero(hcon->sco_data);\n    hci_dev_unlock(hdev);\n\nbut the pointer is cleared from the other side without that lock. When\nthe last sco_conn reference is dropped, sco_conn_free() ran\n\n    conn->hcon->sco_data = NULL;\n\nwith no hdev->lock held, so the RX path could read hcon->sco_data and\ncall kref_get_unless_zero() on an sco_conn that was concurrently freed:\n\n    BUG: KASAN: slab-use-after-free in sco_conn_hold_unless_zero+0xbe/0x160\n    Write of size 4 by task kworker/u17:0\n    Workqueue: hci0 hci_rx_work\n    Call Trace:\n     sco_conn_hold_unless_zero+0xbe/0x160\n     sco_recv_scodata+0x13f/0x490\n     hci_rx_work+0x3af/0x730\n\nkref_get_unless_zero() only guards against a zero refcount, not against\nthe backing memory already being freed.\n\nGive hcon->sco_data an actual reference on the sco_conn it points to, so\nthe object cannot be freed while the pointer is still installed, and only\nclear and drop it from sco_conn_del(), which runs under hdev->lock (its\ncallers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in\nsco_recv_scodata() also takes hdev->lock, so the store and the read are\nnow serialised: the RX path either observes NULL or a reference that is\nguaranteed to stay valid until it drops its own.\n\nsco_conn_add() no longer hands its kref_init() reference to the caller as\nthe connection's only reference; that initial reference is the one owned\nby hcon->sco_data, and callers get their own via sco_conn_hold().\n\nBecause the sco_conn can now outlive the socket (the association keeps it\nalive until the link goes down), the hci_conn can no longer be dropped\nfrom sco_conn_free() without regressing socket close: closing a connected\nSCO socket must still tear the link down. Move hci_conn ownership to the\nsocket instead: __sco_chan_add() takes an hci_conn reference and it is\nreleased from sco_chan_del() and sco_sock_destruct(), exactly once. The\nsco_conn no longer owns an hci_conn reference, so sco_conn_add() stops\nconsuming one and sco_connect() drops the hci_connect_sco() reference on\nevery path; sco_connect_cfm() no longer needs its hci_conn_hold() dance.","Type":"Description","Title":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_sco"}]}}}