In the Linux kernel, the following vulnerability has been resolved: ethtool: cmis: require exact CDB reply length Malicious SFP module could respond… (CVE-2026-63996)
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.
AI Analysis
Technical Summary
The Linux kernel's ethtool cmis driver previously allowed out-of-bounds writes due to insufficient validation of the length of CDB replies from SFP modules. Specifically, if a malicious or buggy SFP module responded with a reply length longer than what cmis_cdb_process_reply() expected, the kernel would cast the reply payload to fixed-layout structures without verifying the length, leading to potential memory corruption. The patch enforces exact reply length checks and adds warnings to aid debugging. This vulnerability affects kernel code that interacts with SFP modules via ethtool and is mitigated by improved defensive programming in the driver.
Potential Impact
A malicious or buggy SFP module could cause out-of-bounds memory writes in the Linux kernel's ethtool cmis driver by sending longer-than-expected CDB replies. This could lead to kernel memory corruption, potentially destabilizing the system or causing undefined behavior. However, exploitation requires physical or logical access to insert or emulate a malicious SFP module, making practical exploitation less likely. No known exploits in the wild have been reported.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to require exact CDB reply lengths in the ethtool cmis driver, preventing out-of-bounds writes. Users should update their Linux kernel to a version that includes this patch. Since this is a kernel-level fix, no additional mitigation steps are required beyond applying the official kernel update. Patch status is not explicitly confirmed in the provided data; users should verify the vendor advisory or kernel changelogs for the exact fixed version.
In the Linux kernel, the following vulnerability has been resolved: ethtool: cmis: require exact CDB reply length Malicious SFP module could respond… (CVE-2026-63996)
Description
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.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's ethtool cmis driver previously allowed out-of-bounds writes due to insufficient validation of the length of CDB replies from SFP modules. Specifically, if a malicious or buggy SFP module responded with a reply length longer than what cmis_cdb_process_reply() expected, the kernel would cast the reply payload to fixed-layout structures without verifying the length, leading to potential memory corruption. The patch enforces exact reply length checks and adds warnings to aid debugging. This vulnerability affects kernel code that interacts with SFP modules via ethtool and is mitigated by improved defensive programming in the driver.
Potential Impact
A malicious or buggy SFP module could cause out-of-bounds memory writes in the Linux kernel's ethtool cmis driver by sending longer-than-expected CDB replies. This could lead to kernel memory corruption, potentially destabilizing the system or causing undefined behavior. However, exploitation requires physical or logical access to insert or emulate a malicious SFP module, making practical exploitation less likely. No known exploits in the wild have been reported.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to require exact CDB reply lengths in the ethtool cmis driver, preventing out-of-bounds writes. Users should update their Linux kernel to a version that includes this patch. Since this is a kernel-level fix, no additional mitigation steps are required beyond applying the official kernel update. Patch status is not explicitly confirmed in the provided data; users should verify the vendor advisory or kernel changelogs for the exact fixed version.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-cwvw-p4x2-27qh
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63996"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912df18
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:02:01 UTC
Last updated: 07/20/2026, 21:51:26 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.