Description
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.
Published: 2026-10-23
Score: 5.3 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Memory exhaustion via uncontrolled skb leak
Action: Apply Patch
AI Analysis

Impact

The bug resides in the Linux kernel’s Bluetooth RFCOMM subsystem, where incoming data frames are handed off to a callback without freeing the socket buffer (skb) when the data link connection (DLC) has no owner. Each unfreed skb consumes memory and the leak grows as the remote side continues to send data. Over time this can exhaust system memory, potentially causing an application or kernel crash and degrading overall system performance, which effectively results in a denial‑of‑service condition.

Affected Systems

All Linux distributions running a kernel that includes the earlier RFCOMM driver before the commit that implements the skb free are vulnerable. This includes any kernel version where the Bluetooth RFCOMM code has not yet applied the fix, regardless of vendor‑specific version numbers.

Risk and Exploitability

The CVSS score of 5.3 denotes medium severity while the EPSS score of <1% indicates a low but non‑zero likelihood of exploitation. The vulnerability is not listed in the CISA KEV catalog. The likely attack vector is an attacker establishing a Bluetooth RFCOMM connection to the target device and transmitting a large volume of data while the DLC remains unowned; this does not require elevated privileges. If successful, the continuous memory leak can accumulate to the point of exhausting available RAM, resulting in service disruption.

Generated by OpenCVE AI on October 29, 2026 at 21:17 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the kernel patch that frees the skb when the DLC has no owner, as referenced in the advisory and associated commit logs.
  • If the patch is not yet available for your distribution, disable RFCOMM or block all Bluetooth traffic at a lower layer until the kernel is updated.
  • Monitor system memory usage for abnormal growth in skb allocations and configure alerts for memory thresholds to detect potential exploitation early.

Generated by OpenCVE AI on October 29, 2026 at 21:17 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 30 Oct 2026 13:00:00 +0000


Thu, 29 Oct 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401

Thu, 29 Oct 2026 12:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-772
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.3, 'vector': 'CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Sat, 24 Oct 2026 02:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux linux
Vendors & Products Linux linux

Fri, 23 Oct 2026 15:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401

Fri, 23 Oct 2026 12:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Bluetooth: RFCOMM: free the skb when the DLC has no owner
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-30T12:40:55.508Z

Reserved: 2026-09-25T10:25:14.385Z

Link: CVE-2026-99010

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-23T13:17:23.620

Modified: 2026-10-30T13:21:36.900

Link: CVE-2026-99010

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-23T00:00:00Z

Links: CVE-2026-99010 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-29T21:30:15Z

Weaknesses
  • CWE-772

    Missing Release of Resource after Effective Lifetime