CVE-2026-90093

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

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.

AC:LAttack complexity, low

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.

PR:LPrivileges required, low

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.

UI:NUser interaction, none

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.

S:UScope, unchanged

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.

C:HConfidentiality impact, high

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.

I:HIntegrity impact, high

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.

A:HAvailability impact, high

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.