Cloudanix VulnDB

CVE-2026-99010

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A Bluetooth component in Linux can slowly leak memory when certain connections are active, eventually making the system slower or unstable.

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

What it actually does

Unconditional skb leak in rfcomm_recv_data when a connected RFCOMM DLC has a cleared owner pointer; the socket data_ready path returns without freeing while rfcomm_process_dlcs continues granting credits, allowing unbounded allocation growth.

Why it matters to the business

Bluetooth RFCOMM socket users on Linux kernels experience gradual memory exhaustion that can degrade performance or trigger OOM conditions on long-lived connections; urgency is low given minimal EPSS and no KEV listing two days after disclosure.

How an attack unfolds

An attacker establishes an RFCOMM connection, triggers rfcomm_sock_destruct to clear the owner while the DLC remains active, then sends repeated data frames; each frame is passed to the callback without being freed and credits are continuously replenished so the remote keeps transmitting.

How to fix it

Apply the upstream fix that adds kfree_skb in the socket data_ready path when the DLC has no owner; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the kfree_skb call in rfcomm_recv_data or rfcomm_sk_data_ready after the owner check; run Bluetooth RFCOMM stress tests that detach sockets and verify skb counters do not grow.

Typical attack path

  1. Establish RFCOMM DLC over Bluetooth L2CAP
  2. Force owner detachment via socket destruction path while DLC state remains BT_CONNECTED
  3. Transmit data frames that rfcomm_recv_data hands to rfcomm_sk_data_ready
  4. Observe repeated skb allocations with no corresponding frees as credits are re-granted

How to detect it

Inspect kernel logs and slab statistics for sustained sk_buff growth correlated with active RFCOMM sessions; correlate with Bluetooth connection establishment and owner-clearing events in rfcomm_sock_destruct.

What your security team should do

  • Patch Bluetooth-enabled Linux systems with the RFCOMM skb fix at the next maintenance window
  • Monitor kernel memory usage and slabinfo for sk_buff growth on hosts exposing RFCOMM sockets
  • Temporarily disable RFCOMM if the workload permits until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: free the skb when the DLC has no owner rfcomm_recv_data() hands the skb to d->data_ready() and returns 0 without freeing it, so the callback owns the skb from that point on. The tty implementation frees it when the DLC has been detached from its device: static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc, struct sk_buff *skb) { struct rfcomm_dev *dev = dlc->owner; if (!dev) { kfree_skb(skb); return; } The socket implementation returns without freeing it, and the skb is leaked. A connected DLC can have no owner: rfcomm_sock_destruct() clears d->owner, while the DLC itself stays on the session until it is closed. Data frames that arrive in that window still find d->state == BT_CONNECTED in rfcomm_recv_data() and are handed to the callback, one leaked skb each. The leak does not stop on its own either. The remote runs out of credits only once RFCOMM_RX_THROTTLED is set, and for a socket the only place that sets it is rfcomm_sk_data_ready() itself, below the return. rfcomm_process_dlcs() keeps granting credits, so the remote keeps sending and the leak keeps growing. Free the skb, as the tty side does.

Affected packages

Ecosystem Package Introduced Fixed