GHSA-25CM-2563-466G

Vulnerability from github – Published: 2026-07-19 18:31 – Updated: 2026-07-20 15:31
VLAI
Details

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

net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring

When an sk_msg scatterlist ring wraps (sg.end < sg.start), tls_push_record() chains the tail portion of the ring to the head using sg_chain(). An extra entry in the sg array is reserved for this:

struct sk_msg_sg { [...] / The extra two elements: * 1) used for chaining the front and sections when the list becomes * partitioned (e.g. end < start). The crypto APIs require the * chaining; * 2) to chain tailer SG entries after the message. / struct scatterlist data[MAX_MSG_FRAGS + 2];

The current code uses MAX_SKB_FRAGS + 1 as the ring size:

sg_chain(&msg_pl->sg.data[msg_pl->sg.start],
         MAX_SKB_FRAGS - msg_pl->sg.start + 1,
         msg_pl->sg.data);

This places the chain pointer at

sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. = &data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 = data[start + (MAX_SKB_FRAGS - start + 1) - 1] = data[MAX_SKB_FRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: sk_msg, zap ingress queue on psock down")

Convert to ARRAY_SIZE and drop the data[start] / - start (as suggested by Sabrina).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-64047"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:45Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring\n\nWhen an sk_msg scatterlist ring wraps (sg.end \u003c sg.start),\ntls_push_record() chains the tail portion of the ring to the head\nusing sg_chain(). An extra entry in the sg array is reserved for\nthis:\n\n  struct sk_msg_sg {\n        [...]\n        /* The extra two elements:\n         * 1) used for chaining the front and sections when the list becomes\n         *    partitioned (e.g. end \u003c start). The crypto APIs require the\n         *    chaining;\n         * 2) to chain tailer SG entries after the message.\n         */\n        struct scatterlist              data[MAX_MSG_FRAGS + 2];\n\nThe current code uses MAX_SKB_FRAGS + 1 as the ring size:\n\n    sg_chain(\u0026msg_pl-\u003esg.data[msg_pl-\u003esg.start],\n             MAX_SKB_FRAGS - msg_pl-\u003esg.start + 1,\n             msg_pl-\u003esg.data);\n\nThis places the chain pointer at\n\n  sg_chain(data[start], (MAX_SKB_FRAGS - msg_start + 1) .. =\n  \u0026data[start] + (MAX_SKB_FRAGS - msg_start + 1) - 1 =\n  data[start + (MAX_SKB_FRAGS - start + 1) - 1] =\n  data[MAX_SKB_FRAGS]\n\ninstead of the true last entry. This is likely due to a \"race\" of\nthe commit under Fixes landing close to\ncommit 031097d9e079 (\"bpf: sk_msg, zap ingress queue on psock down\")\n\nConvert to ARRAY_SIZE and drop the data[start] / - start (as suggested\nby Sabrina).",
  "id": "GHSA-25cm-2563-466g",
  "modified": "2026-07-20T15:31:57Z",
  "published": "2026-07-19T18:31:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64047"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/131ef12057d92b77b636321b7849c69222405a97"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/285943c6e7ca309bbea84b253745154241d9788a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2fb0dc7e0099686c4e9d2732745d8a31b18c3628"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/47110c3a9ac247b688657337f5981efcfcb240dc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/66339b71f105e6f83e0da3b9583d95077534fe1d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/73963a375885d5ccb7def39fd0b4f542e0f343dd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/84158c2997159df4a0d70cd9c46774512d32a522"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eca989eab4b2599dcb02f72140a7c08f08838520"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…