Vulnerability-Lookup

CVE-2026-64551 (GCVE-0-2026-64551)

Vulnerability from cvelistv5 – Published: 2026-07-27 20:10 – Updated: 2026-08-17 04:57

Title

sctp: validate STALE_COOKIE cause length before reading staleness

Summary

In the Linux kernel, the following vulnerability has been resolved: sctp: validate STALE_COOKIE cause length before reading staleness When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header: err = (struct sctp_errhdr *)(chunk->skb->data); stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err))); err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory. sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded. The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.

Severity

9.1 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

Assigner

Linux mitre root

References

8 references

URL	Tags
https://git.kernel.org/stable/c/6022da37786701df1…
https://git.kernel.org/stable/c/861f884f5471632c7…
https://git.kernel.org/stable/c/588706ebaf8cdb4a4…
https://git.kernel.org/stable/c/a257b41ddfe9e327b…
https://git.kernel.org/stable/c/08a8f2d13f7039243…
https://git.kernel.org/stable/c/ebe0a55d954fa8da3…
https://git.kernel.org/stable/c/bbd6b2ea966cf57b6…
https://git.kernel.org/stable/c/1cd23ca80784223fa…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 6022da37786701df1fc5dd946a6dcba59d5473b1 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 861f884f5471632c731cbbd612a1c072e391a624 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 588706ebaf8cdb4a4161602949eba365514b1db1 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < a257b41ddfe9e327b26581ad2777f04b23ac73f5 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 08a8f2d13f703924316e9aeac863a88ef50990c7 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < ebe0a55d954fa8da383b6192edb8f763dcb002d5 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 1cd23ca80784223fa2204e16203f754da4e821f8 (git)	guessed
Linux	Linux	Affected: 2.6.12 Unaffected: 0 , < 2.6.12 (semver) Unaffected: 5.10.261 , ≤ 5.10.* (semver) Unaffected: 5.15.212 , ≤ 5.15.* (semver) Unaffected: 6.1.178 , ≤ 6.1.* (semver) Unaffected: 6.6.145 , ≤ 6.6.* (semver) Unaffected: 6.12.97 , ≤ 6.12.* (semver) Unaffected: 6.18.40 , ≤ 6.18.* (semver) Unaffected: 7.1.5 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/sctp/sm_statefuns.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6022da37786701df1fc5dd946a6dcba59d5473b1",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "861f884f5471632c731cbbd612a1c072e391a624",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "588706ebaf8cdb4a4161602949eba365514b1db1",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "a257b41ddfe9e327b26581ad2777f04b23ac73f5",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "08a8f2d13f703924316e9aeac863a88ef50990c7",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "ebe0a55d954fa8da383b6192edb8f763dcb002d5",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            },
            {
              "lessThan": "1cd23ca80784223fa2204e16203f754da4e821f8",
              "status": "affected",
              "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/sctp/sm_statefuns.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.12"
            },
            {
              "lessThan": "2.6.12",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.261",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.212",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.178",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.145",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.97",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.40",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.5",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.261",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.212",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.178",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.145",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.97",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.40",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.5",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "2.6.12",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk-\u003eskb-\u003edata);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb-\u003etail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The vulnerable code is in the SCTP receive-side state machine and is driven entirely by an attacker-crafted ERROR chunk arriving over the network; no local access is needed. Per kernel guidance, net/ stack bugs reachable via received packets (SCTP explicitly) are Network.\nAC:L - The attacker fully controls the trigger: acting as the SCTP peer it answers INIT with INIT-ACK to place the association in COOKIE_ECHOED, then sends a minimal ERROR chunk with a 4-byte STALE_COOKIE cause as the last chunk in the packet. There is no race, no memory-layout dependency, and the vtag needed is the one the victim itself advertised in its INIT.\nPR:N - SCTP association setup is unauthenticated; the only check is sctp_vtag_verify() against a tag the peer already received in the victim\u0027s INIT. The attacker needs no credentials or privileges on the target system.\nUI:N - No human user action is required \u2014 SCTP client daemons (SIGTRAN, Diameter, cluster transports) establish and retry associations automatically, and an on-path attacker can inject the ERROR into an in-progress handshake. In the local variant an unprivileged process creates both sides itself with no user involved.\nS:U - The out-of-bounds read and the resulting disclosure stay within the kernel\u0027s own security authority; no VM, sandbox, or IOMMU boundary is crossed.\nC:H - Uninitialized kernel memory past skb-\u003etail is read and then transmitted straight back to the attacker inside the reply INIT\u0027s Cookie Preservative parameter, and the attack can be repeated indefinitely to sample recycled network-buffer memory that may contain remnants of other connections\u0027 traffic. This is a remote, unauthenticated, repeatable kernel heap disclosure oracle, matching the C:H treatment given to the sibling SCTP uninit-read CVE-2026-53225.\nI:N - The bug is a pure read; nothing in kernel memory or in the victim\u0027s association state is modified. The only affected value is a protocol field in a packet sent to the attacker itself.\nA:H - The read runs past the end of the received packet data, a memory-safety violation whose target is not proven to remain inside the skb\u0027s allocation across all receive paths (GSO/frag_list segments, UDP-encapsulated and linearized skbs), so it can fault and oops; kernel guidance and the CNA\u0027s scoring of the equivalent SCTP out-of-bounds-read bug both treat this class as A:H."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:57:28.771Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6022da37786701df1fc5dd946a6dcba59d5473b1"
        },
        {
          "url": "https://git.kernel.org/stable/c/861f884f5471632c731cbbd612a1c072e391a624"
        },
        {
          "url": "https://git.kernel.org/stable/c/588706ebaf8cdb4a4161602949eba365514b1db1"
        },
        {
          "url": "https://git.kernel.org/stable/c/a257b41ddfe9e327b26581ad2777f04b23ac73f5"
        },
        {
          "url": "https://git.kernel.org/stable/c/08a8f2d13f703924316e9aeac863a88ef50990c7"
        },
        {
          "url": "https://git.kernel.org/stable/c/ebe0a55d954fa8da383b6192edb8f763dcb002d5"
        },
        {
          "url": "https://git.kernel.org/stable/c/bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0"
        },
        {
          "url": "https://git.kernel.org/stable/c/1cd23ca80784223fa2204e16203f754da4e821f8"
        }
      ],
      "title": "sctp: validate STALE_COOKIE cause length before reading staleness",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-64551",
    "datePublished": "2026-07-27T20:10:40.012Z",
    "dateReserved": "2026-07-19T15:36:31.796Z",
    "dateUpdated": "2026-08-17T04:57:28.771Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-64551",
      "date": "2026-09-29",
      "epss": "0.00514",
      "percentile": "0.41483"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "net/sctp/sm_statefuns.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "6022da37786701df1fc5dd946a6dcba59d5473b1",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "861f884f5471632c731cbbd612a1c072e391a624",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "588706ebaf8cdb4a4161602949eba365514b1db1",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "a257b41ddfe9e327b26581ad2777f04b23ac73f5",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "08a8f2d13f703924316e9aeac863a88ef50990c7",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ebe0a55d954fa8da383b6192edb8f763dcb002d5",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "1cd23ca80784223fa2204e16203f754da4e821f8",
                    "status": "affected",
                    "version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "net/sctp/sm_statefuns.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "2.6.12"
                  },
                  {
                    "lessThan": "2.6.12",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.261",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.212",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.178",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.145",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.97",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.40",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.1.*",
                    "status": "unaffected",
                    "version": "7.1.5",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk-\u003eskb-\u003edata);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb-\u003etail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace."
          }
        ],
        "id": "CVE-2026-64551",
        "lastModified": "2026-08-17T05:18:00.557",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 9.1,
                "baseSeverity": "CRITICAL",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 5.2,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-07-27T21:17:08.020",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/08a8f2d13f703924316e9aeac863a88ef50990c7"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/1cd23ca80784223fa2204e16203f754da4e821f8"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/588706ebaf8cdb4a4161602949eba365514b1db1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6022da37786701df1fc5dd946a6dcba59d5473b1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/861f884f5471632c731cbbd612a1c072e391a624"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/a257b41ddfe9e327b26581ad2777f04b23ac73f5"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/ebe0a55d954fa8da383b6192edb8f763dcb002d5"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-07-30T08:27:59+00:00",
      "cve": "CVE-2026-64551",
      "id": "CVE-2026-64551",
      "initial_release_date": "2026-07-27T00:00:00+00:00",
      "product_status:known_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: sctp: validate STALE_COOKIE cause length before reading staleness",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-64551.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-09-23T00:21:49Z",
      "cve": "CVE-2026-64551",
      "id": "CVE-2026-64551",
      "initial_release_date": "2026-07-28T17:07:54Z",
      "product_status:first_fixed": "68",
      "product_status:known_affected": "636",
      "product_status:known_not_affected": "43",
      "product_status:recommended": "134",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-64551",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-64551.json",
      "version": "14"
    }
  }
}

GHSA-M58P-8FJH-3WHJ

Vulnerability from github – Published: 2026-07-27 21:31 – Updated: 2026-07-30 06:32

Details

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

sctp: validate STALE_COOKIE cause length before reading staleness

When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header:

err   = (struct sctp_errhdr *)(chunk->skb->data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));

err is the first cause in the chunk, not the STALE_COOKIE cause that caused the dispatch, and nothing guarantees the staleness field is present. sctp_walk_errors() only requires a cause to be as long as the 4-byte header, so for a STALE_COOKIE cause of length 4 the read runs past the cause, and for a minimal ERROR chunk past skb->tail. The value is echoed to the peer in the Cookie Preservative of the reply INIT, leaking uninitialized memory.

sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so check its length there and pass it to sctp_sf_do_5_2_6_stale(), which reads that cause instead of the first one. A STALE_COOKIE cause too short to hold the staleness field is discarded.

The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-64551"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-27T21:17:08Z",
    "severity": "CRITICAL"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk-\u003eskb-\u003edata);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb-\u003etail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace.",
  "id": "GHSA-m58p-8fjh-3whj",
  "modified": "2026-07-30T06:32:34Z",
  "published": "2026-07-27T21:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64551"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/08a8f2d13f703924316e9aeac863a88ef50990c7"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1cd23ca80784223fa2204e16203f754da4e821f8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/588706ebaf8cdb4a4161602949eba365514b1db1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6022da37786701df1fc5dd946a6dcba59d5473b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/861f884f5471632c731cbbd612a1c072e391a624"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a257b41ddfe9e327b26581ad2777f04b23ac73f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bbd6b2ea966cf57b6ae095cf5a8dbc993cd197a0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ebe0a55d954fa8da383b6192edb8f763dcb002d5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

OESA-2026-3705 (CVE-2026-53309)

Vulnerability from osv_openeuler – Published: 2026-09-14 16:33 – Updated: 2026-09-14 16:33 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison

The local-vs-remote region comparison loop uses '<=' instead of '<', causing it to read one entry past the valid range of qr_regions. The other loops in the same function correctly use '<'.

Fix the loop condition to use '<' for consistency and correctness.(CVE-2026-53309)

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

ixgbevf: fix use-after-free in VEPA multicast source pruning

ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:

dev_kfree_skb_irq(skb);
continue;

The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):

BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)

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

sctp: validate STALE_COOKIE cause length before reading staleness

When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header:

err   = (struct sctp_errhdr *)(chunk-&gt;skb-&gt;data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));

The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.(CVE-2026-64551)

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

libceph: fix two unsafe bare decodes in decode_lockers()

decode_lockers() in cls_lock_client.c contains two bare decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads:

ceph_decode_32(p) at the num_lockers field has no preceding bounds check. ceph_start_decoding() accepts struct_len=0 as valid -- the internal ceph_decode_need(p, end, 0, bad) always passes -- so when an OSD sends struct_len=0, ceph_start_decoding() returns success with p == end. The immediately following bare ceph_decode_32(p) then reads 4 bytes past the validated buffer boundary. The garbage value is passed directly to kzalloc_objs() as the locker count.

The sibling function decode_watchers() in osd_client.c already uses ceph_decode_32_safe() after its own ceph_start_decoding() call. decode_lockers() was the only site using the bare variant.

ceph_decode_8(p) after the decode_locker() loop has no preceding bounds check. If an OSD crafts num_lockers such that the loop advances p exactly to end, the subsequent bare ceph_decode_8(p) reads one byte past the validated buffer boundary. The result is passed directly into *type, which is used as a lock type discriminator by callers, giving an OSD-controlled one-byte OOB read with direct influence over the lock type field.

Fix both by replacing bare operations with their safe variants: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, type, err_free_lockers)

The goto targets differ intentionally: err_inval: is a new label returning -EINVAL directly. It is used for the pre-allocation failure path where *lockers is not yet allocated and must not be passed to ceph_free_lockers().

err_free_lockers: is the existing label. It is used for the post-allocation failure path where *lockers is allocated and must be freed.

ret is set to -EINVAL before ceph_decode_8_safe() so that err_free_lockers returns the correct error code on bounds violation. Without this, err_free_lockers would return a stale ret value (0 from the successful decode_locker() loop), silently swallowing the error.

-EINVAL is correct for both failure paths. The data received from the OSD is structurally malformed. -ENOMEM would misrepresent the failure class to callers and to stable@ backporters triaging error paths.

Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.get_info class method (e.g. during RBD exclusive lock acquisition).

idryomov: trim changelog, formatting

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

dmaengine: Fix possible use after free

In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However, dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA provider is already gone and hence free it.

Fixes it by moving dma_chan_put() after the check.(CVE-2026-72476)

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

RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one

Free the UAR index returned by the hardware.(CVE-2026-74296)

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

RDMA/mlx5: Fix undefined shift of user RQ WQE size

set_rq_size() computes the RQ WQE size as "1 << rq_wqe_shift" based on the user-provided rq_wqe_shift, which is only checked to be greater than 32, so shifts of 32 are still accepted. A shift of 31 also overflows a signed integer, leading to undefined behavior.

Use check_shl_overflow() to compute the RQ WQE size and reject any invalid values.(CVE-2026-74297)

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

vhost/net: complete zerocopy ubufs only once

vhost-net initializes one ubuf_info per outstanding zerocopy TX descriptor and hands it to the backend socket. The networking stack may then clone a zerocopy skb before all skb references are released. For example, batman-adv fragmentation reaches skb_split(), which calls skb_zerocopy_clone() and increments the same ubuf_info refcount.

vhost_zerocopy_complete() currently treats every ubuf callback as a completed vhost descriptor. It dereferences ubuf->ctx, writes the descriptor completion state, and drops the vhost_net_ubuf_ref even when the callback only releases a cloned skb reference. A backend reset can therefore wait for and free the vhost_net_ubuf_ref while another cloned skb still carries the same ubuf_info. A later completion then dereferences the freed ubufs pointer.

KASAN reports the stale completion as:

BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0 BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0 vhost_zerocopy_complete skb_copy_ubufs __dev_forward_skb2 veth_xmit

The freed object was allocated from vhost_net_ioctl() while setting the backend and freed through kfree_rcu()/kvfree_rcu_bulk after backend removal, while delayed skb completion still reached vhost_zerocopy_complete().

Honor the generic ubuf_info refcount before touching vhost state, and run the vhost descriptor completion only for the final ubuf reference. This matches the msg_zerocopy_complete() ownership rule for cloned zerocopy skbs.(CVE-2026-74310)

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

bpf: Preserve pointer state for commuted arithmetic

When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields.

Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent.(CVE-2026-74720)

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

libceph: Avoid using invalid osd indices from primary_temp

A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts that don't exist, i.e., that are greater than max_osd or smaller than CEPH_HOMELESS_OSD (-1). These indices are used to create the up and acting set in ceph_pg_to_up_acting_osds(), called from calc_target(). While most of these osd indices are checked, the one from primary_temp is not. Subsequently, this may lead to calc_target() returning this (potentially invalid) index as target osd for a (linger) request. Because the osd_state, osd_weight, and osd_addr arrays only contain max_osd entries (with indices 0 to max_osd -1), this leads to out-of-bounds accesses when trying to read values from these arrays.

This patch fixes the issue by adding a check to get_temp_osds(), so that only valid osd indices from primary_temp are used, and it falls back to using the primary from pg_temp or the up set if it is invalid.

idryomov: changelog

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53309	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64113	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64551	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-68082	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-72476	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74296	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74297	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74310	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-74720	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-80558	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2609.1.0.0389.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2609.1.0.0389.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2609.1.0.0389.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison\n\nThe local-vs-remote region comparison loop uses \u0026apos;\u0026lt;=\u0026apos; instead of \u0026apos;\u0026lt;\u0026apos;,\ncausing it to read one entry past the valid range of qr_regions.  The\nother loops in the same function correctly use \u0026apos;\u0026lt;\u0026apos;.\n\nFix the loop condition to use \u0026apos;\u0026lt;\u0026apos; for consistency and correctness.(CVE-2026-53309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix use-after-free in VEPA multicast source pruning\n\nixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF\u0026apos;s\nown address (VEPA multicast workaround) by freeing the skb and\ncontinuing to the next descriptor:\n\n    dev_kfree_skb_irq(skb);\n    continue;\n\nThe skb pointer is declared outside the while loop and persists across\niterations.  Because the continue skips the \u0026quot;skb = NULL\u0026quot; reset at the\nbottom of the loop, the next iteration enters the \u0026quot;else if (skb)\u0026quot; path\nand calls ixgbevf_add_rx_frag() on the freed skb, dereferencing\nskb_shinfo(skb)-\u0026gt;nr_frags - a use-after-free in NAPI softirq context.\n\nThe sibling driver iavf already handles this correctly by nulling the\npointer before continuing.  Apply the same pattern here.\n\nI do not have ixgbevf hardware; the bug was found by static analysis\n(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool\ncorroboration with the highest score in the scan).  The UAF was confirmed\nunder KASAN by loading a test module that reproduces the exact code\npattern (alloc skb, kfree_skb, then read skb_shinfo(skb)-\u0026gt;nr_frags):\n\n  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000\n  Read of size 8 at addr 000000006163ae78 by task insmod/30\n  freed 208-byte region [000000006163adc0, 000000006163ae90)\n\nQEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF\ndriver does not include the VEPA source pruning path, so a full\nend-to-end reproduction with emulated hardware was not possible.(CVE-2026-64113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk-\u0026gt;skb-\u0026gt;data);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb-\u0026gt;tail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace.(CVE-2026-64551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix two unsafe bare decodes in decode_lockers()\n\ndecode_lockers() in cls_lock_client.c contains two bare decode operations\nthat allow a malicious or compromised OSD to trigger slab-out-of-bounds\nreads:\n\n1. ceph_decode_32(p) at the num_lockers field has no preceding bounds\n   check. ceph_start_decoding() accepts struct_len=0 as valid -- the\n   internal ceph_decode_need(p, end, 0, bad) always passes -- so when an\n   OSD sends struct_len=0, ceph_start_decoding() returns success with\n   p == end. The immediately following bare ceph_decode_32(p) then reads\n   4 bytes past the validated buffer boundary. The garbage value is\n   passed directly to kzalloc_objs() as the locker count.\n\n   The sibling function decode_watchers() in osd_client.c already uses\n   ceph_decode_32_safe() after its own ceph_start_decoding() call.\n   decode_lockers() was the only site using the bare variant.\n\n2. ceph_decode_8(p) after the decode_locker() loop has no preceding\n   bounds check. If an OSD crafts num_lockers such that the loop\n   advances p exactly to end, the subsequent bare ceph_decode_8(p) reads\n   one byte past the validated buffer boundary. The result is passed\n   directly into *type, which is used as a lock type discriminator by\n   callers, giving an OSD-controlled one-byte OOB read with direct\n   influence over the lock type field.\n\nFix both by replacing bare operations with their safe variants:\n  ceph_decode_32(p) -\u0026gt; ceph_decode_32_safe(p, end, *num_lockers,\n                                           err_inval)\n  ceph_decode_8(p)  -\u0026gt; ceph_decode_8_safe(p, end, *type,\n                                          err_free_lockers)\n\nThe goto targets differ intentionally:\n  err_inval: is a new label returning -EINVAL directly. It is used for\n  the pre-allocation failure path where *lockers is not yet allocated\n  and must not be passed to ceph_free_lockers().\n\n  err_free_lockers: is the existing label. It is used for the\n  post-allocation failure path where *lockers is allocated and must\n  be freed.\n\nret is set to -EINVAL before ceph_decode_8_safe() so that\nerr_free_lockers returns the correct error code on bounds violation.\nWithout this, err_free_lockers would return a stale ret value (0 from\nthe successful decode_locker() loop), silently swallowing the error.\n\n-EINVAL is correct for both failure paths. The data received from the\nOSD is structurally malformed. -ENOMEM would misrepresent the failure\nclass to callers and to stable@ backporters triaging error paths.\n\nAttacker model: a malicious or compromised OSD in a multi-tenant Ceph\ndeployment can trigger this against any kernel client that issues the\nlock.get_info class method (e.g. during RBD exclusive lock acquisition).\n\n[ idryomov: trim changelog, formatting ](CVE-2026-68082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix possible use after free\n\nIn dma_release_channel(), check chan-\u0026gt;device-\u0026gt;privatecnt after call\ndma_chan_put(). However, dma_chan_put() call dma_device_put() which could\nrelease the last reference of the device if the DMA provider is already\ngone and hence free it.\n\nFixes it by moving dma_chan_put() after the check.(CVE-2026-72476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Release the HW\u2011provided UAR index rather than the SW one\n\nFree the UAR index returned by the hardware.(CVE-2026-74296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix undefined shift of user RQ WQE size\n\nset_rq_size() computes the RQ WQE size as \u0026quot;1 \u0026lt;\u0026lt; rq_wqe_shift\u0026quot; based on\nthe user-provided rq_wqe_shift, which is only checked to be greater than\n32, so shifts of 32 are still accepted. A shift of 31 also overflows a\nsigned integer, leading to undefined behavior.\n\nUse check_shl_overflow() to compute the RQ WQE size and reject any\ninvalid values.(CVE-2026-74297)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost/net: complete zerocopy ubufs only once\n\nvhost-net initializes one ubuf_info per outstanding zerocopy TX\ndescriptor and hands it to the backend socket.  The networking stack may\nthen clone a zerocopy skb before all skb references are released.  For\nexample, batman-adv fragmentation reaches skb_split(), which calls\nskb_zerocopy_clone() and increments the same ubuf_info refcount.\n\nvhost_zerocopy_complete() currently treats every ubuf callback as a\ncompleted vhost descriptor.  It dereferences ubuf-\u0026gt;ctx, writes the\ndescriptor completion state, and drops the vhost_net_ubuf_ref even when\nthe callback only releases a cloned skb reference.  A backend reset can\ntherefore wait for and free the vhost_net_ubuf_ref while another cloned\nskb still carries the same ubuf_info.  A later completion then\ndereferences the freed ubufs pointer.\n\nKASAN reports the stale completion as:\n\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x1d7/0x1f0\n  BUG: KASAN: slab-use-after-free in vhost_zerocopy_complete+0x101/0x1f0\n  vhost_zerocopy_complete\n  skb_copy_ubufs\n  __dev_forward_skb2\n  veth_xmit\n\nThe freed object was allocated from vhost_net_ioctl() while setting the\nbackend and freed through kfree_rcu()/kvfree_rcu_bulk after backend\nremoval, while delayed skb completion still reached\nvhost_zerocopy_complete().\n\nHonor the generic ubuf_info refcount before touching vhost state, and run\nthe vhost descriptor completion only for the final ubuf reference.  This\nmatches the msg_zerocopy_complete() ownership rule for cloned zerocopy\nskbs.(CVE-2026-74310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Preserve pointer state for commuted arithmetic\n\nWhen scalar += pointer is handled in adjust_ptr_min_max_vals(), the\ndestination register inherits the pointer state from the source pointer.\nCopying only selected fields is fragile because pointer provenance is\ntracked by several bpf_reg_state fields.\n\nUse the caller\u0026apos;s temporary offset register to preserve the scalar operand\nwhile replacing the destination with the full pointer state. This preserves\nthe frame number for PTR_TO_STACK registers and keeps parent identity\nfields consistent.(CVE-2026-74720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: Avoid using invalid osd indices from primary_temp\n\nA corrupted osdmap received from a Ceph monitor or OSD may contain osd\nindices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts\nthat don\u0026apos;t exist, i.e., that are greater than max_osd or smaller than\nCEPH_HOMELESS_OSD (-1). These indices are used to create the up and\nacting set in ceph_pg_to_up_acting_osds(), called from calc_target().\nWhile most of these osd indices are checked, the one from primary_temp\nis not. Subsequently, this may lead to calc_target() returning this\n(potentially invalid) index as target osd for a (linger) request.\nBecause the osd_state, osd_weight, and osd_addr arrays only contain\nmax_osd entries (with indices 0 to max_osd -1), this leads to\nout-of-bounds accesses when trying to read values from these arrays.\n\nThis patch fixes the issue by adding a check to get_temp_osds(), so that\nonly valid osd indices from primary_temp are used, and it falls back to\nusing the primary from pg_temp or the up set if it is invalid.\n\n[ idryomov: changelog ](CVE-2026-80558)",
  "id": "OESA-2026-3705",
  "modified": "2026-09-14T16:33:32Z",
  "published": "2026-09-14T16:33:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64113"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64551"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74297"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74310"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74720"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80558"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-53309",
    "CVE-2026-64113",
    "CVE-2026-64551",
    "CVE-2026-68082",
    "CVE-2026-72476",
    "CVE-2026-74296",
    "CVE-2026-74297",
    "CVE-2026-74310",
    "CVE-2026-74720",
    "CVE-2026-80558"
  ]
}

OESA-2026-3986 (CVE-2026-64551)

Vulnerability from osv_openeuler – Published: 2026-09-20 13:23 – Updated: 2026-09-20 13:23 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

sctp: validate STALE_COOKIE cause length before reading staleness

When an ERROR chunk with a STALE_COOKIE cause is received in the COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure of Staleness that follows the cause header:

err   = (struct sctp_errhdr *)(chunk-&gt;skb-&gt;data);
stale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));

The read is reachable by any peer that can drive an association into COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket in a user and network namespace.(CVE-2026-64551)

Severity

9.1 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64551	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-332.0.0.233.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-332.0.0.233.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-332.0.0.233.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: validate STALE_COOKIE cause length before reading staleness\n\nWhen an ERROR chunk with a STALE_COOKIE cause is received in the\nCOOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure\nof Staleness that follows the cause header:\n\n\terr   = (struct sctp_errhdr *)(chunk-\u0026gt;skb-\u0026gt;data);\n\tstale = ntohl(*(__be32 *)((u8 *)err + sizeof(*err)));\n\nerr is the first cause in the chunk, not the STALE_COOKIE cause that\ncaused the dispatch, and nothing guarantees the staleness field is\npresent. sctp_walk_errors() only requires a cause to be as long as the\n4-byte header, so for a STALE_COOKIE cause of length 4 the read runs\npast the cause, and for a minimal ERROR chunk past skb-\u0026gt;tail. The value\nis echoed to the peer in the Cookie Preservative of the reply INIT,\nleaking uninitialized memory.\n\nsctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so\ncheck its length there and pass it to sctp_sf_do_5_2_6_stale(), which\nreads that cause instead of the first one. A STALE_COOKIE cause too\nshort to hold the staleness field is discarded.\n\nThe read is reachable by any peer that can drive an association into\nCOOKIE_ECHOED, including an unprivileged process using a raw SCTP socket\nin a user and network namespace.(CVE-2026-64551)",
  "id": "OESA-2026-3986",
  "modified": "2026-09-20T13:23:51Z",
  "published": "2026-09-20T13:23:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3986"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64551"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-64551"
  ]
}

OPENSUSE-SU-2026:11476-1

Vulnerability from csaf_opensuse - Published: 2026-08-09 00:00 - Updated: 2026-09-26 08:35

Summary

kernel-devel-7.1.7-1.1 on GA media

Severity

Moderate

Scope

351 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2026:21910-1

Vulnerability from csaf_opensuse - Published: 2026-09-22 15:26 - Updated: 2026-09-29 08:23

Summary

Security update for the Linux Kernel

Severity

Important

Scope

885 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 136 products

Open the full advisory

SUSE-SU-2026:23477-1

Vulnerability from csaf_suse - Published: 2026-09-08 12:54 - Updated: 2026-09-29 08:19

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 4 products

Open the full advisory

SUSE-SU-2026:23481-1

Vulnerability from csaf_suse - Published: 2026-09-08 13:00 - Updated: 2026-09-29 08:19

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 11 products

Open the full advisory

SUSE-SU-2026:23528-1

Vulnerability from csaf_suse - Published: 2026-09-08 10:34 - Updated: 2026-09-29 08:19

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 7 products

Open the full advisory

SUSE-SU-2026:23529-1

Vulnerability from csaf_suse - Published: 2026-09-08 11:00 - Updated: 2026-09-29 08:19

Summary

Security update for the Linux Kernel

Severity

Important

Scope

588 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 17 products

Open the full advisory

SUSE-SU-2026:4120-1

Vulnerability from csaf_suse - Published: 2026-09-10 09:31 - Updated: 2026-09-29 08:20

Summary

Security update for the Linux Kernel

Severity

Important

Scope

662 vulnerabilities in this advisory, including CVE-2026-64551.

CVE-2026-64551

5.3 (Medium)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Recommended: 19 products

Open the full advisory

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted

CVE-2026-64551 (GCVE-0-2026-64551)

OESA-2026-3705 (CVE-2026-53309)

OESA-2026-3986 (CVE-2026-64551)

Tags

Sightings

Nomenclature

Related by attack behaviour