Vulnerability-Lookup

GHSA-439P-4PHC-PPRQ

Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-13 09:32

Details

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

net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry

smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes.

Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry.

The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed.

Severity

8.2 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-80985"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-11T20:19:05Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: carry oversized SMC-Rv2 LLC messages in the queue entry\n\nsmc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part\nof a v2 message that does not fit into the 44-byte union smc_llc_msg, and\nboth bound themselves by the size of the buffer it landed in, not by what\narrived. On a link with a shared v2 receive buffer a 44-byte\nDELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an\nearlier message left in lgr-\u003ewr_rx_buf_v2, and passes each of them to\nsmc_rtoken_delete(). One of those 255 matched a registered rtoken and\ndeleted it. An ADD_LINK on such a link installs up to 255 rtokens from\nthe same bytes.\n\nCopy the tail into the queue entry, so its length is the length of the\nmessage that arrived, and declare the rkeys that fit inline as a member of\nthe union instead of reaching them through a cast. The same\nDELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited\nto the longest tail the two functions can read, so the peer does not pick\nthe size of the entry.\n\nThe bound the previous patch placed on links without a shared v2 receive\nbuffer is no longer needed.",
  "id": "GHSA-439p-4phc-pprq",
  "modified": "2026-09-13T09:32:10Z",
  "published": "2026-09-11T21:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80985"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0d6f80be8ac5886842640d6526abf3f9a215be75"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d3c1ab82c11d4fadebf817a825fd221b3e197ea"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/edf30d65e3ac52f886f7d87b1a7449742e79157d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CVE-2026-80985 (GCVE-0-2026-80985)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:42 – Updated: 2026-10-19 08:46

Title

net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry

Summary

In the Linux kernel, the following vulnerability has been resolved: net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part of a v2 message that does not fit into the 44-byte union smc_llc_msg, and both bound themselves by the size of the buffer it landed in, not by what arrived. On a link with a shared v2 receive buffer a 44-byte DELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an earlier message left in lgr->wr_rx_buf_v2, and passes each of them to smc_rtoken_delete(). One of those 255 matched a registered rtoken and deleted it. An ADD_LINK on such a link installs up to 255 rtokens from the same bytes. Copy the tail into the queue entry, so its length is the length of the message that arrived, and declare the rkeys that fit inline as a member of the union instead of reaching them through a cast. The same DELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited to the longest tail the two functions can read, so the peer does not pick the size of the entry. The bound the previous patch placed on links without a shared v2 receive buffer is no longer needed.

Severity

8.2 (High)


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

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6639 records in the last 180 days details

References

3 references

URL	Tags
https://git.kernel.org/stable/c/edf30d65e3ac52f88…
https://git.kernel.org/stable/c/0d6f80be8ac588684…
https://git.kernel.org/stable/c/8d3c1ab82c11d4fad…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: 27ef6a9981fe74191849966a6d5e0400a4008ab8 , < edf30d65e3ac52f886f7d87b1a7449742e79157d (git) Affected: 27ef6a9981fe74191849966a6d5e0400a4008ab8 , < 0d6f80be8ac5886842640d6526abf3f9a215be75 (git) Affected: 27ef6a9981fe74191849966a6d5e0400a4008ab8 , < 8d3c1ab82c11d4fadebf817a825fd221b3e197ea (git)
Linux	Linux	Affected: 6.14 Unaffected: 0 , < 6.14 (semver) Unaffected: 6.18.50 , ≤ 6.18.* (semver) Unaffected: 7.2.4 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "net/smc/smc_llc.c",
            "net/smc/smc_wr.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "edf30d65e3ac52f886f7d87b1a7449742e79157d",
              "status": "affected",
              "version": "27ef6a9981fe74191849966a6d5e0400a4008ab8",
              "versionType": "git"
            },
            {
              "lessThan": "0d6f80be8ac5886842640d6526abf3f9a215be75",
              "status": "affected",
              "version": "27ef6a9981fe74191849966a6d5e0400a4008ab8",
              "versionType": "git"
            },
            {
              "lessThan": "8d3c1ab82c11d4fadebf817a825fd221b3e197ea",
              "status": "affected",
              "version": "27ef6a9981fe74191849966a6d5e0400a4008ab8",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "net/smc/smc_llc.c",
            "net/smc/smc_wr.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.14"
            },
            {
              "lessThan": "6.14",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.50",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3",
                  "versionStartIncluding": "6.14",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: carry oversized SMC-Rv2 LLC messages in the queue entry\n\nsmc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys() read the part\nof a v2 message that does not fit into the 44-byte union smc_llc_msg, and\nboth bound themselves by the size of the buffer it landed in, not by what\narrived. On a link with a shared v2 receive buffer a 44-byte\nDELETE_RKEY_V2 declaring 255 rkeys reaches rkey[9..254] in whatever an\nearlier message left in lgr-\u003ewr_rx_buf_v2, and passes each of them to\nsmc_rtoken_delete(). One of those 255 matched a registered rtoken and\ndeleted it. An ADD_LINK on such a link installs up to 255 rtokens from\nthe same bytes.\n\nCopy the tail into the queue entry, so its length is the length of the\nmessage that arrived, and declare the rkeys that fit inline as a member of\nthe union instead of reaching them through a cast. The same\nDELETE_RKEY_V2 now processes the 9 rkeys it carries. The copy is limited\nto the longest tail the two functions can read, so the peer does not pick\nthe size of the entry.\n\nThe bound the previous patch placed on links without a shared v2 receive\nbuffer is no longer needed."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - A remote SMC-Rv2 peer delivers DELETE_RKEY_V2 and ADD_LINK LLC messages over the RDMA QP after the TCP CLC handshake; RoCEv2 is IP/UDP-routable (port 4791) and SMC-Rv2 supports routed peers. smc_llc_rx_handler runs from the RDMA completion path with no local syscall.\nAC:L - The attacker controls the prior oversized LLC payload that fills the shared lgr-\u003ewr_rx_buf_v2 spillover and the later 44-byte DELETE_RKEY_V2 or ADD_LINK that declares up to 255 rkeys, so leftover bytes are attacker-chosen. No race, lucky layout, or rare non-default config is required on the usual max_recv_sge\u003e=2 path.\nPR:N - SMC performs no peer authentication; smc_create() has no capability check, and LLC DELETE_RKEY/ADD_LINK run after an unauthenticated CLC handshake. Any network peer that completes SMC-R v2 to a listener reaches smc_llc_rmt_delete_rkey() and smc_llc_save_add_link_rkeys().\nUI:N - Incoming LLC messages are demultiplexed from the RDMA receive completion tasklet into smc_llc_event_work. A listening SMC-R server processes DELETE_RKEY_V2 automatically with no victim user action.\nS:U - The corrupted rtoken table lives in the same kernel security authority as the SMC-R stack; this does not cross a VM, IOMMU, or sandbox boundary.\nC:N - Leftover bytes are prior peer LLC payloads in the shared 8KiB wr_rx_buf_v2, not adjacent kernel objects, so the extra rkey walks do not disclose kernel memory. Rtokens are remote keys used only for outbound RDMA writes to that same peer.\nI:L - Leftover rkeys are passed to smc_rtoken_delete() and leftover ADD_LINK extensions are written via smc_rtoken_set(), so registered rtokens can be cleared or remapped on a new link. That is limited corruption of the LGR rtoken table, not an arbitrary kernel write.\nA:H - Deleting a live rtoken zeros its rkey and dma_addr while connections still use that slot, so later smc_tx_rdma_write() posts fail and smcr_link_down tears down the link group. A peer can repeat this at will and fully deny SMC-R on the LGR."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-19T08:46:09.624Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/edf30d65e3ac52f886f7d87b1a7449742e79157d"
        },
        {
          "url": "https://git.kernel.org/stable/c/0d6f80be8ac5886842640d6526abf3f9a215be75"
        },
        {
          "url": "https://git.kernel.org/stable/c/8d3c1ab82c11d4fadebf817a825fd221b3e197ea"
        }
      ],
      "title": "net/smc: carry oversized SMC-Rv2 LLC messages in the queue entry",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-80985",
    "datePublished": "2026-09-11T19:42:44.243Z",
    "dateReserved": "2026-08-26T14:34:25.811Z",
    "dateUpdated": "2026-10-19T08:46:09.624Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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