---
id: CVE-2026-99010
title: 'Bluetooth: RFCOMM: free the skb when the DLC has no owner'
summary: |-
  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 th…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <
    a54ce160e3ef7e50ec94e0ac4131c3d0f9f739b9
  - >-
    Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <
    c3f76b025cbbb0ab47310dbe7de18092d89f2a99
  - >-
    Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <
    4f46de658ce61968aef5ea7ae809d1c180330544
  - >-
    Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <
    b8814161b14c610b7a09527433301d8ad8180aef
  - >-
    Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <
    9d1afbf60ed53c5b051cd124153e0ae3078c8b93
  - Linux 2.6.12
published: '2026-10-23'
updated: '2026-10-23'
sourceUpdated: '2026-10-23T12:20:35.485Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-99010'
references:
  - url: 'https://git.kernel.org/stable/c/a54ce160e3ef7e50ec94e0ac4131c3d0f9f739b9'
  - url: 'https://git.kernel.org/stable/c/c3f76b025cbbb0ab47310dbe7de18092d89f2a99'
  - url: 'https://git.kernel.org/stable/c/4f46de658ce61968aef5ea7ae809d1c180330544'
  - url: 'https://git.kernel.org/stable/c/b8814161b14c610b7a09527433301d8ad8180aef'
  - url: 'https://git.kernel.org/stable/c/9d1afbf60ed53c5b051cd124153e0ae3078c8b93'
tags:
  - cve.org
ingestedAt: '2026-10-23T13:24:55.537Z'
---

## Overview

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

- `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < a54ce160e3ef7e50ec94e0ac4131c3d0f9f739b9`
- `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < c3f76b025cbbb0ab47310dbe7de18092d89f2a99`
- `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 4f46de658ce61968aef5ea7ae809d1c180330544`
- `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < b8814161b14c610b7a09527433301d8ad8180aef`
- `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 9d1afbf60ed53c5b051cd124153e0ae3078c8b93`
- `Linux 2.6.12`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.