{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-90092", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-90092" ], "published": "2026-09-17T16:10:40Z", "summary": "Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: reject accept queue add unless BT_LISTEN\n\nNew sk should not be added to parent socket accept queue after last\nl2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and\nstate set to BT_CLOSED, as that can result to UAF on dereferencing the\ndangling parent reference.\n\nl2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown,\ndue to chan->state accessed without consistent locking:\n\n [Task 1] [Task 2]\n l2cap_sock_release(parent) l2cap_connect\n l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm\n l2cap_chan_lock(pchan)\n l2cap_chan_close\n l2cap_sock_teardown_cb\n pchan->state = BT_CLOSED\n l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan)\n l2cap_new_connection\n l2cap_sock_new_connection_cb\n l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan)\n l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */\n\nFix by adding check for sk_state == BT_LISTEN after acquiring sk lock in\nl2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes\nwhere missing, to avoid data races.\n\nAlthough the data races on pchan->state should be fixed too, this\ndefensive sk_state check probably makes sense in any case.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.12.93-1+rpt1", "1:6.12.96-1+rpt1", "1:6.12.109-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.12.93+rpt-rpi-2712", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.93+rpt-rpi-v6", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.93+rpt-rpi-v7", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.93+rpt-rpi-v7l", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.93+rpt-rpi-v8", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.93+rpt-rpi-v8-rt", "binary_version": "1:6.12.93-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-2712", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-v6", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-v7", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-v7l", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-v8", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.96+rpt-rpi-v8-rt", "binary_version": "1:6.12.96-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-2712", "binary_version": "1:6.12.109-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-v6", "binary_version": "1:6.12.109-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-v7", "binary_version": "1:6.12.109-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-v7l", "binary_version": "1:6.12.109-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-v8", "binary_version": "1:6.12.109-1+rpt1" }, { "binary_name": "linux-image-6.12.109+rpt-rpi-v8-rt", "binary_version": "1:6.12.109-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.12.93-1+rpt1": { "linux_commit": "d8ab4e908235da7727f22dd36ad5af224671677d", "upstream_version": "6.12.93", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.110" }, "1:6.12.96-1+rpt1": { "linux_commit": "ae161617d7a4552fa91d03626b8d9f3696d17481", "upstream_version": "6.12.96", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.110" }, "1:6.12.109-1+rpt1": { "linux_commit": "7d1826930811232688a50c99c540fbb137aed081", "upstream_version": "6.12.109", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.12.110" } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-2712", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v6", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v7", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8-rt", "binary_version": "1:6.18.50-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-90092" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/bf61a65c6093970e3b50031c4b79ebf3bd411eba" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/491e4c60017969b053888029998d2a61f298986a" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/2a3a27aaf19bf069720e024ce6fde54e6bf80df9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/87276dc15b559d32757a43b4415c8445fbae06c4" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c47339e169bf4a0a4cfabb91351471f67744c2bc" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/d4bfa78fd67929b62b02013c107973e0c5b7aa9a" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-18T17:55:42Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 8.0, "cvss_v3_severity": "High", "scenario": "AV:A - The UAF is reached when a remote peer's L2CAP Connection Request (L2CAP_CONN_REQ, L2CAP_LE_CONN_REQ, or L2CAP_ECRED_CONN_REQ) is delivered via hci_acldata_packet() \u2192 l2cap_recv_acldata() \u2192 l2cap_recv_frame() into l2cap_connect()/l2cap_le_connect_req(), which calls l2cap_new_connection() \u2192 l2cap_sock_new_connection_cb(). Bluetooth radio range is adjacent.\nAC:L - The race is between the attacker's close() of their listening socket (l2cap_sock_release() \u2192 l2cap_sock_teardown_cb() setting BT_CLOSED, then l2cap_sock_kill()) and an in-flight L2CAP_CONN_REQ that already passed l2cap_global_chan_by_psm(BT_LISTEN) and is waiting on the chan lock. The attacker owns both sides and can retry.\nPR:L - Triggering the parent-free half requires owning the listener: l2cap_sock_create() has no capability check for SOCK_SEQPACKET/SOCK_STREAM, and l2cap_validate_le_psm()/l2cap_validate_bredr_psm() allow dynamic PSMs (\u22650x0080 LE, \u22650x1001 BR/EDR) without CAP_NET_BIND_SERVICE. smp_sufficient_security() returns true at default BT_SECURITY_LOW, so the LE connect side needs no pairing.\nUI:N - The attacker close()s their own L2CAP listen fd and sends L2CAP Connection Requests from a radio they control; no victim pairing prompt, mount, or other user action is required to reach l2cap_sock_new_connection_cb() or the later l2cap_sock_ready_cb() dereference.\nS:U - The use-after-free corrupts the listening kernel struct sock in kmalloc-2k and stays within the kernel's own security authority; it is not a VM, IOMMU, or sandbox escape.\nC:H - syzbot KASAN reports a slab-use-after-free Read in l2cap_sock_ready_cb() of the parent sock already freed by l2cap_sock_release()\u2192__sk_destruct(). The child's dangling bt_sk(sk)->parent is then used to load parent->sk_data_ready from the freed kmalloc-2k object, so spraying that cache discloses kernel memory.\nI:H - l2cap_sock_ready_cb() calls parent->sk_data_ready(parent) on the freed sock, hijacking a function pointer, and l2cap_sock_teardown_cb() may still run bt_accept_unlink() which list_del_init()s and writes sk_ack_backlog on that same freed parent, giving a write/CFI primitive.\nA:H - The same dangling-parent load in l2cap_sock_ready_cb() is a confirmed slab-use-after-free (syzbot KASAN splat from l2cap_info_timeout()\u2192l2cap_chan_ready()) that oopses or panics the kernel even without a completed exploit." } } }