{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-99011 in the wild and no public exploit code.","fix":"Upgrade to a fixed version.","what":"CVE-2026-99011 is a high-severity vulnerability in Linux, published on 23 Oct 2026."},"fix_prompt":"Check this codebase for CVE-2026-99011 and fix it if it is affected.\n\nWhat it is: CVE-2026-99011 is a high-severity vulnerability in Linux, published on 23 Oct 2026. \nExploitation: There is no known exploitation of CVE-2026-99011 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-99011/ (Markdown: https://insights.sbomify.com/CVE-2026-99011/index.md)","id":"CVE-2026-99011","markdown":"https://insights.sbomify.com/CVE-2026-99011/index.md","name":"CVE-2026-99011","record":{"aliases":["BELL-CVE-2026-99011","DEBIAN-CVE-2026-99011","GHSA-jp44-3rrh-3mww","UBUNTU-CVE-2026-99011"],"analysis":null,"analysis_generated_by":null,"assigner":"Linux","cpe":[],"cvss":{"score":7.1,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"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-\u003esco_data back-pointer to a\nstrong reference under hdev-\u003elock:\n\n    hci_dev_lock(hdev);\n    hcon = hci_conn_hash_lookup_handle(hdev, handle);\n    ...\n    conn = sco_conn_hold_unless_zero(hcon-\u003esco_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-\u003ehcon-\u003esco_data = NULL;\n\nwith no hdev-\u003elock held, so the RX path could read hcon-\u003esco_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-\u003esco_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-\u003elock (its\ncallers, sco_connect_cfm() and sco_disconn_cfm(), hold it). The reader in\nsco_recv_scodata() also takes hdev-\u003elock, 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-\u003esco_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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()","id":"CVE-2026-99011","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":null,"year":"2026"},"n_packages":0,"n_references":3,"next":{"headline":"Bluetooth: ISO: Serialize concurrent connect calls","id":"CVE-2026-99012"},"packages":[],"prev":{"headline":"Bluetooth: RFCOMM: free the skb when the DLC has no owner","id":"CVE-2026-99010"},"products":["Linux"],"published":"2026-10-23","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-24","vendors":["Linux"]},"summary":null,"url":"https://insights.sbomify.com/CVE-2026-99011/"}