GHSA-7365-W977-M58V

Vulnerability from github – Published: 2026-10-23 15:31 – Updated: 2026-10-23 15:31
VLAI
Details

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.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-99010"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-23T13:17:23Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: RFCOMM: free the skb when the DLC has no owner\n\nrfcomm_recv_data() hands the skb to d-\u003edata_ready() and returns 0\nwithout freeing it, so the callback owns the skb from that point on.\nThe tty implementation frees it when the DLC has been detached from its\ndevice:\n\n  static void rfcomm_dev_data_ready(struct rfcomm_dlc *dlc,\n                                    struct sk_buff *skb)\n  {\n          struct rfcomm_dev *dev = dlc-\u003eowner;\n\n          if (!dev) {\n                  kfree_skb(skb);\n                  return;\n          }\n\nThe socket implementation returns without freeing it, and the skb is\nleaked.\n\nA connected DLC can have no owner: rfcomm_sock_destruct() clears\nd-\u003eowner, while the DLC itself stays on the session until it is closed.\nData frames that arrive in that window still find d-\u003estate ==\nBT_CONNECTED in rfcomm_recv_data() and are handed to the callback, one\nleaked skb each.\n\nThe leak does not stop on its own either.  The remote runs out of\ncredits only once RFCOMM_RX_THROTTLED is set, and for a socket the only\nplace that sets it is rfcomm_sk_data_ready() itself, below the return.\nrfcomm_process_dlcs() keeps granting credits, so the remote keeps\nsending and the leak keeps growing.\n\nFree the skb, as the tty side does.",
  "id": "GHSA-7365-w977-m58v",
  "modified": "2026-10-23T15:31:34Z",
  "published": "2026-10-23T15:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99010"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4f46de658ce61968aef5ea7ae809d1c180330544"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d1afbf60ed53c5b051cd124153e0ae3078c8b93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a54ce160e3ef7e50ec94e0ac4131c3d0f9f739b9"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b8814161b14c610b7a09527433301d8ad8180aef"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c3f76b025cbbb0ab47310dbe7de18092d89f2a99"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.