Cloudanix VulnDB

CVE-2026-98455

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in Linux Bluetooth software can make devices crash when receiving certain connection messages from nearby devices.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in the Linux kernel RFCOMM getsockopt handler for RFCOMM_CONNINFO when a deferred-setup socket has its session cleared by a prior DISC frame while defer_setup flag remains set.

Why it matters to the business

Linux systems using Bluetooth can experience kernel crashes or panics triggered by remote Bluetooth peers, leading to loss of availability and requiring reboots; the issue affects devices five days after disclosure with no widespread exploitation observed.

How an attack unfolds

An attacker establishes a BR/EDR ACL link, opens L2CAP on the RFCOMM PSM, initiates a session with SABM on a channel using BT_DEFER_SETUP, accepts the socket, then sends DISC; this clears the session pointer while leaving defer_setup set, so a subsequent getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) dereferences NULL.

How to fix it

Apply the upstream kernel patch that restricts the deferred-setup exception to BT_CONNECT2 state and verifies a session exists before dereferencing; rebuild and deploy updated kernels to all affected Linux systems; disable Bluetooth where it is not required as a temporary mitigation.

How to confirm the fix worked

Confirm the kernel version contains commit 43a556b2fd43 or later equivalent fix; test by reproducing the QEMU/vhci sequence with a KASAN-enabled kernel and verify no NULL dereference occurs on getsockopt after DISC; check /proc/config.gz or kernel build logs for the corrected rfcomm_sock_getsockopt logic.

Typical attack path

  1. Establish ACL and L2CAP connection to target RFCOMM PSM
  2. Send SABM to create DLC with defer_setup enabled
  3. Accept the child socket on the listening socket
  4. Send DISC to force state to BT_CLOSED and unlink the session
  5. Call getsockopt on the accepted socket to trigger the NULL dereference

How to detect it

Search kernel logs for general protection faults or KASAN reports referencing rfcomm_sock_getsockopt and null-ptr-deref at offset 0x10 of struct rfcomm_session; inspect audit or syslog entries around Bluetooth connection establishment and teardown events.

  • rfcomm_sock_getsockopt+0x529/0x780
  • KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
  • Oops: general protection fault, probably for non-canonical address

What your security team should do

  • Prioritize kernel updates on all Linux Bluetooth hosts within the next maintenance window
  • Monitor EPSS and threat intel feeds for any increase in exploit maturity
  • Temporarily disable RFCOMM or Bluetooth on high-risk endpoints until patched
  • Add kernel oops monitoring for rfcomm_sock_getsockopt symbols to SIEM

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: fix NULL dereference of dlc->session in RFCOMM_CONNINFO The RFCOMM_CONNINFO getsockopt handler accepts a socket that is not connected as long as deferred setup is enabled: if (sk->sk_state != BT_CONNECTED && !rfcomm_pi(sk)->dlc->defer_setup) { err = -ENOTCONN; break; } l2cap_sk = rfcomm_pi(sk)->dlc->session->sock->sk; dlc->defer_setup is set in rfcomm_sock_init() when rfcomm_connect_ind() creates a child socket for an incoming connection on a listening socket that has BT_DEFER_SETUP enabled. It is never cleared afterwards. The session, however, can go away underneath it. rfcomm_recv_disc() forces the dlc state before tearing it down: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); The RFCOMM_DEFER_SETUP early return in __rfcomm_dlc_close() only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2, so with the state already BT_CLOSED that switch does not match and the function falls through to rfcomm_dlc_unlink(), which sets d->session = NULL, while d->defer_setup stays 1. A getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket after that point therefore skips the -ENOTCONN path -- sk->sk_state is BT_CLOSED, but dlc->defer_setup is still set -- and dereferences the NULL session. No race is needed: once the DISC has been processed, the dereference is unconditional. Reproduced on a KASAN kernel under QEMU with a BR/EDR peer emulated over /dev/vhci: the peer brings up an ACL link, opens L2CAP on the RFCOMM PSM, starts a session and sends SABM for a channel bound with BT_DEFER_SETUP, and sends DISC for that dlci after the socket has been accepted. getsockopt(SOL_RFCOMM, RFCOMM_CONNINFO) on the accepted socket then hits: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 150 Comm: init Tainted: G B 7.3.0-rc3-g5dd1818b15d9 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:rfcomm_sock_getsockopt+0x529/0x780 Call Trace: <TASK> do_sock_getsockopt+0x3ad/0x7d0 __sys_getsockopt+0x10e/0x1b0 __x64_sys_getsockopt+0xc2/0x160 do_syscall_64+0xda/0x4b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> 0x10 is the offset of sock in struct rfcomm_session; rfcomm_sock_getsockopt_old() is inlined into rfcomm_sock_getsockopt(). Commit 43a556b2fd43 ("Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept") fixed the same "a remote DISC clears the session while deferred setup is still flagged" problem in rfcomm_dlc_accept(); this is the remaining instance of it, in the getsockopt path. Deferred setup only leaves a socket usable here once it has reached BT_CONNECT2, so restrict the exception to that state and check that a session is actually present before following it.

Affected packages

Ecosystem Package Introduced Fixed