CVE Catalog

CVE-2026-63996

HighCVSS 7.8
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.13%

3th percentile - higher than 3% of all known CVEs

Summary

In the Linux kernel, a vulnerability in the ethtool cmis module allows a malicious SFP module to respond with a reply length (rpl_len) larger than expected by cmis_cdb_process_reply(), causing an out-of-bounds (OOB) write. This affects potentially malicious hardware as well as buggy or corrupted modules.

Risk Assessment

An attacker could exploit this vulnerability to perform out-of-bounds writes, potentially leading to data corruption, system crash, or privilege escalation within the Linux kernel.

Recommendation

Immediately update the Linux kernel to a version containing the fix (commit addressing the issue). Monitor Linux distribution security advisories for the appropriate patch.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS