GHSA-CWVW-P4X2-27QH

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:

ethtool: cmis: require exact CDB reply length

Malicious SFP module could respond with rpl_len longer than what cmis_cdb_process_reply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel.

The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rpl_exp_len cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling:

  • cmis_cdb_validate_password()
  • cmis_cdb_module_features_get()
  • cmis_fw_update_fw_mng_features_get()

so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong...

Note that page_data->length (argument of kmalloc) comes from last arg to ethtool_cmis_page_init() which is rpl_exp_len.

Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-63996"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T16:17:39Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis: require exact CDB reply length\n\nMalicious SFP module could respond with rpl_len longer than\nwhat cmis_cdb_process_reply() expected, leading to OOB writes.\nMalicious HW is a bit theoretical but some modules may just\nbe buggy and/or the reads may occasionally get corrupted,\nso let\u0027s protect the kernel.\n\nThe existing check protects from short replies. We need to\nprotect from long ones, too. All callers that pass a non-zero\nrpl_exp_len cast the reply payload to a fixed-layout struct\nand read fields at fixed offsets, with no version negotiation\nor short-reply handling:\n\n  - cmis_cdb_validate_password()\n  - cmis_cdb_module_features_get()\n  - cmis_fw_update_fw_mng_features_get()\n\nso let\u0027s assume that responses longer than expected do not\nhave to be handled gracefully here. Add a warning message\nto make the debug easier in case my understanding is wrong...\n\nNote that page_data-\u003elength (argument of kmalloc) comes from\nlast arg to ethtool_cmis_page_init() which is rpl_exp_len.\n\nNote2 that AIs also like to point out overflows in args-\u003ereq.payload\nitself (which is a fixed-size 120 B buffer, on the stack),\nbut callers should be reading structs defined by the standard,\nso protecting from requests for more data than max seem like\ndefensive programming.",
  "id": "GHSA-cwvw-p4x2-27qh",
  "modified": "2026-07-20T15:31:54Z",
  "published": "2026-07-19T18:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63996"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f818cc98fd2c63a08239cb48995f6c3bfe9d9b3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4d42fb88ec61f2e98c33a9e3a2de371d5edbc6b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6c3f999a9d1338c6c89a9ff4549eafe72bc2e7b1"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb5dcd740cd7fa27bc2caeff2d28ef28e93ff4d3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/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.





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.