GHSA-8H97-6438-987H

Vulnerability from github – Published: 2026-04-22 15:31 – Updated: 2026-04-27 15:30
VLAI?
Details

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req

Syzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd() that is triggered by a malformed Enhanced Credit Based Connection Request.

The vulnerability stems from l2cap_ecred_conn_req(). The function allocates a local stack buffer (pdu) designed to hold a maximum of 5 Source Channel IDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more than 5 SCIDs, the function calculates rsp_len based on this unvalidated cmd_len before checking if the number of SCIDs exceeds L2CAP_ECRED_MAX_CID.

If the SCID count is too high, the function correctly jumps to the response label to reject the packet, but rsp_len retains the attacker's oversized value. Consequently, l2cap_send_cmd() is instructed to read past the end of the 18-byte pdu buffer, triggering a KASAN panic.

Fix this by moving the assignment of rsp_len to after the num_scid boundary check. If the packet is rejected, rsp_len will safely remain 0, and the error response will only read the 8-byte base header from the stack.

Severity ?
8.1 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-31513"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T14:16:50Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req\n\nSyzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd()\nthat is triggered by a malformed Enhanced Credit Based Connection Request.\n\nThe vulnerability stems from l2cap_ecred_conn_req(). The function allocates\na local stack buffer (`pdu`) designed to hold a maximum of 5 Source Channel\nIDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more\nthan 5 SCIDs, the function calculates `rsp_len` based on this unvalidated\n`cmd_len` before checking if the number of SCIDs exceeds\nL2CAP_ECRED_MAX_CID.\n\nIf the SCID count is too high, the function correctly jumps to the\n`response` label to reject the packet, but `rsp_len` retains the\nattacker\u0027s oversized value. Consequently, l2cap_send_cmd() is instructed\nto read past the end of the 18-byte `pdu` buffer, triggering a\nKASAN panic.\n\nFix this by moving the assignment of `rsp_len` to after the `num_scid`\nboundary check. If the packet is rejected, `rsp_len` will safely\nremain 0, and the error response will only read the 8-byte base header\nfrom the stack.",
  "id": "GHSA-8h97-6438-987h",
  "modified": "2026-04-27T15:30:39Z",
  "published": "2026-04-22T15:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31513"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5b35f8211a913cfe7ab9d54fa36a272d2059a588"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/9d87cb22195b2c67405f5485d525190747ad5493"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a3d9c50d69785ae02e153f000da1b5fd6dbfdf1b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c8e1a27edb8b4e5afb56b384acd7b6c2dec1b7cc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.