Cloudanix VulnDB

CVE-2026-80819

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux Bluetooth code handling certain connection setups can let a nearby device crash the system by sending a specific close message.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Null pointer dereference in rfcomm_dlc_accept() called from rfcomm_sock_recvmsg() on the RFCOMM_DEFER_SETUP path without rfcomm_mutex held, allowing a remote DISC to clear d->session before the dereference of session->sock->sk.

Why it matters to the business

Bluetooth RFCOMM connections using BT_DEFER_SETUP sockets can trigger kernel crashes or denial of service from remote peers; widespread impact on Linux systems with Bluetooth enabled, though exploitation requires specific socket configuration and timing.

How an attack unfolds

Attacker establishes an ACL/L2CAP/RFCOMM session to a socket bound with BT_DEFER_SETUP, opens a DLC, then sends a DISC frame that forces BT_CLOSED state and unlinks the session while leaving the DEFER_SETUP bit set; subsequent recvmsg on the accepted socket performs an unconditional null dereference.

How to fix it

Apply the upstream fix that wraps rfcomm_dlc_accept() with rfcomm_mutex and re-checks the session pointer; distributions should backport the change to all supported kernels with Bluetooth RFCOMM enabled.

How to confirm the fix worked

Confirm the patched rfcomm_dlc_accept() acquires rfcomm_mutex before accessing d->session; reproduce the reported KASAN/PROVE_LOCKING scenario over /dev/vhci to verify absence of the oops.

Typical attack path

  1. Establish BR/EDR ACL link and L2CAP channel to RFCOMM PSM
  2. Open RFCOMM DLC on a BT_DEFER_SETUP-bound channel
  3. Send RFCOMM DISC to force BT_CLOSED and clear session pointer
  4. Trigger recvmsg on the accepted socket to hit the dereference

How to detect it

Inspect kernel logs for oops or KASAN reports mentioning rfcomm_dlc_accept, rfcomm_sock_recvmsg, and null-ptr-deref at offset 0x10 of struct rfcomm_session; correlate with Bluetooth RFCOMM session teardown events.

  • rfcomm_dlc_accept+0x54
  • KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
  • RFCOMM_DEFER_SETUP
  • rfcomm_sock_recvmsg

What your security team should do

  • Prioritize kernel updates containing the RFCOMM mutex fix on all Bluetooth-enabled systems
  • Disable RFCOMM or BT_DEFER_SETUP sockets where not required
  • Monitor vendor advisories for backported fixes given 25-day publication window

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: take rfcomm_mutex for the deferred setup accept rfcomm_sock_recvmsg() completes a deferred setup by calling rfcomm_dlc_accept() without holding any RFCOMM lock: if (test_and_clear_bit(RFCOMM_DEFER_SETUP, &d->flags)) { rfcomm_dlc_accept(d); return 0; } and rfcomm_dlc_accept() dereferences the session on its first line: struct sock *sk = d->session->sock->sk; Every other path that touches d->session runs under rfcomm_mutex: rfcomm_dlc_open(), rfcomm_dlc_close(), rfcomm_dlc_exists(), rfcomm_dlc_send_rpn(), and the RFCOMM thread through rfcomm_process_sessions(). rfcomm_connect_ind() is even documented as "called under rfcomm_lock()". This call site is the only one that skips it. The RFCOMM_DEFER_SETUP bit looks like it serialises the accept against teardown, since __rfcomm_dlc_close() returns early when it wins the test_and_clear. But rfcomm_recv_disc() forces the state first: d->state = BT_CLOSED; __rfcomm_dlc_close(d, err); and the early return only covers BT_CONNECT, BT_CONFIG, BT_OPEN and BT_CONNECT2. With the state already BT_CLOSED that switch does not match, the bit is never consulted, and __rfcomm_dlc_close() falls through to rfcomm_dlc_unlink(), which sets d->session = NULL. So a remote DISC on a deferred dlc clears the session while leaving RFCOMM_DEFER_SETUP set. The next recvmsg() then passes the test_and_clear and dereferences a NULL session. No timing window is needed: once the DISC has been processed, the dereference is unconditional. Give rfcomm_dlc_accept() the same shape as rfcomm_dlc_open() and rfcomm_dlc_close(): an exported wrapper that takes rfcomm_mutex and re-checks the session, around a __rfcomm_dlc_accept() that the two in-core callers, which already hold the mutex, keep using. Reproduced on a KASAN + PROVE_LOCKING kernel 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, opens a dlc on a channel bound with BT_DEFER_SETUP, and sends DISC after the socket is accepted. recv() on the accepted socket then hits: Oops: general protection fault KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rfcomm_dlc_accept+0x54/0x350 Call Trace: rfcomm_sock_recvmsg+0x1cd/0x230 sock_recvmsg+0x166/0x1c0 __sys_recvfrom+0x20d/0x300 0x10 is the offset of sock in struct rfcomm_session. With this patch the same run completes with recv() returning 0 and no report, and lockdep stays quiet, confirming rfcomm_mutex is still taken before lock_sock on this path as it is on the thread side.

Affected packages

Ecosystem Package Introduced Fixed