{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-90093", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-90093" ], "published": "2026-09-17T16:10:40Z", "summary": "Bluetooth: L2CAP: access chan->conn safely in get/setsockopt", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: access chan->conn safely in get/setsockopt\n\nSince commit b66774b48dd9 (\"Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref\")\nl2cap_chan::conn has held reference and remains non-NULL also after the\ncorresponding hci_conn is deleted. In this state accessing various\nfields eg. hci_conn::hdev is invalid, which leads to KASAN crash in\nl2cap_sock_setsockopt() access of conn->hcon->hdev.\n\nCheck l2cap_chan::conn.hcon corresponds to an alive hci_conn before\ntrying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in\ngetsockopt/setsockopt to ensure it stays alive, and to avoid data races\nin l2cap_chan fields.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/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.109-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "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.109-1+rpt1": { "linux_commit": "7d1826930811232688a50c99c540fbb137aed081", "upstream_version": "6.12.109", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null } } } }, { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "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.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": null } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-90093" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f49321c85785178214fd67f2e9b4b73d6363783b" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ca2c4c26498643f421d35ffe258fafbd3ed461c3" } ], "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": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The UAF is reached from __sys_setsockopt/__sys_getsockopt_iter into l2cap_sock_setsockopt()/l2cap_sock_getsockopt(), which dereference chan->conn->hcon->hdev after the HCI device is already gone; the trigger is the local BT_FLUSHABLE/BT_SECURITY/BT_PHY sockopt, not a received L2CAP or HCI PDU. Syzbot frees that hdev via vhci_release()->hci_unregister_dev(), which an in-range peer cannot invoke.\nAC:L - After b66774b48dd9, l2cap_chan_del() sets FLAG_DEL but leaves chan->conn non-NULL, so a later setsockopt(SOL_BLUETOOTH, BT_FLUSHABLE, BT_FLUSHABLE_OFF) deterministically hits lmp_no_flush_capable(conn->hcon->hdev) on the deleted hci_conn. The attacker opens the L2CAP socket, tears down the controller (close of /dev/vhci), then issues the sockopt; no un-controllable race or rare config is required.\nPR:L - l2cap_sock_create() requires capable(CAP_NET_RAW) only for SOCK_RAW; SOCK_SEQPACKET/STREAM/DGRAM L2CAP sockets used here have no capability gate, and vhci_open() likewise has no capable() check. An unprivileged init_net user who can open /dev/vhci (or an equivalent HCI node) can create the socket, unregister the controller, and call setsockopt without real root.\nUI:N - The attacker owns both the AF_BLUETOOTH/BTPROTO_L2CAP fd and the teardown fd: they connect, close /dev/vhci so hci_conn_hash_flush()->l2cap_conn_del() runs, then call setsockopt on their still-open socket. No other user must pair, mount, or click anything.\nS:U - l2cap_sock_setsockopt() is using a dangling hci_dev through l2cap_conn->hcon after hci_release_dev(); the resulting slab UAF stays inside the host kernel Bluetooth stack and does not cross a VM, IOMMU, or sandbox authority.\nC:H - KASAN reports a use-after-free/OOB read in l2cap_sock_setsockopt() of conn->hcon->hdev (lmp_no_flush_capable() reads hdev->features[0][6]; getsockopt BT_SECURITY/BT_PHY and L2CAP_CONNINFO also read hcon fields). The freed hci_dev slab was reused as skbuff_small_head, so spraying that object yields a kernel-memory read primitive through the dangling hdev pointer.\nI:H - The same dangling conn->hcon remains usable from setsockopt after FLAG_DEL: BT_SECURITY on an ATT socket calls smp_conn_security(conn->hcon) which touches hcon->hdev flags and hcon->pending_sec_level, and BT_PHY calls hci_conn_set_phy() on that hcon. A sprayed hci_dev in place of the freed object supplies function pointers (send/reset/workqueues) for write and control-flow hijack.\nA:H - Syzbot crashed in l2cap_sock_setsockopt+0x22c3 (net/bluetooth/l2cap_sock.c:1003) with both KASAN slab-out-of-bounds and use-after-free reads of the released hci_dev after vhci_release()->hci_release_dev(). Any such UAF dereference oopses or panics the kernel and can be repeated by open/connect/close/setsockopt." } } }