Cloudanix VulnDB

CVE-2026-99008

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux Bluetooth handling can make the computer crash when certain wireless connections are opened and then closed.

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

What it actually does

NULL pointer dereference in rfcomm_dev_shutdown() when rfcomm_dev_add() adds a device to the list before tty registration succeeds, allowing rfcomm_tty_install() to attach without setting tty_dev and triggering a fault on subsequent close via tty_port_shutdown.

Why it matters to the business

Local denial of service via kernel crash or panic on Linux systems exposing RFCOMM Bluetooth TTY interfaces, leading to unplanned reboots and temporary loss of Bluetooth functionality; low urgency given recent publication, stable low EPSS, and absence from known exploitation lists.

How an attack unfolds

An attacker with local access triggers the race by causing RFCOMM device registration to fail after list insertion, opens the resulting /dev/rfcommN node, then closes it so rfcomm_dev_shutdown dereferences the unset tty_dev pointer.

How to fix it

Apply the upstream kernel patch that adds a NULL check for dev->tty_dev inside rfcomm_dev_shutdown before any operations, matching the existing handling in rfcomm_dev_destruct; rebuild and reboot into the updated kernel.

How to confirm the fix worked

Confirm the patched kernel source contains an explicit dev->tty_dev != NULL guard in rfcomm_dev_shutdown at net/bluetooth/rfcomm/tty.c before the tty_move_to_tail or equivalent call; test by reproducing the original syzbot reproducer and verifying no oops occurs.

Typical attack path

  1. Obtain local user access on an affected Linux kernel
  2. Cause RFCOMM tty device addition with failed tty registration
  3. Open the rfcomm device node to attach via rfcomm_tty_install
  4. Close the tty to invoke rfcomm_dev_shutdown with NULL tty_dev

How to detect it

Inspect dmesg, journalctl, or /var/log/kern.log for oops messages containing rfcomm_dev_shutdown, KASAN null-ptr-deref, or RIP pointing to net/bluetooth/rfcomm/tty.c around line 131; correlate with recent Bluetooth device attach/detach events.

What your security team should do

  • Prioritize kernel updates on systems with Bluetooth RFCOMM enabled within standard patch windows
  • Review logs for rfcomm-related general protection faults or KASAN null-ptr-deref entries
  • Restrict untrusted local accounts from accessing /dev/rfcomm* nodes until patched

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown syzbot hit a NULL pointer dereference in rfcomm_dev_shutdown() when an RFCOMM tty is closed. rfcomm_dev_add() puts the new device on rfcomm_dev_list first and only then registers the tty device and saves it in dev->tty_dev. If that registration fails, dev->tty_dev is never set at all. The device can be looked up in the meantime, so an open() of /dev/rfcommN gets through rfcomm_tty_install() and attaches to it. When that tty is closed again, rfcomm_dev_shutdown() uses dev->tty_dev without checking it: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] RIP: 0010:rfcomm_dev_shutdown+0x48/0xb0 net/bluetooth/rfcomm/tty.c:131 Call Trace: tty_port_shutdown+0x1bf/0x220 drivers/tty/tty_port.c:372 tty_port_close+0x4e/0x150 drivers/tty/tty_port.c:705 tty_release+0x359/0x1670 drivers/tty/tty_io.c:1718 __fput+0x418/0xa50 fs/file_table.c:512 rfcomm_dev_destruct() already copes with a NULL dev->tty_dev. Add the same check to rfcomm_dev_shutdown(), so the tty device is only moved when it was actually registered.

Affected packages

Ecosystem Package Introduced Fixed