CVE-2026-63996 ethtool: cmis: require exact CDB reply length
A malicious or buggy SFP module can trigger out-of-bounds writes in the Linux kernel ethtool CMIS driver, potentially leading to code execution or privilege escalation.
- Exploited in the wild
- Not known
- Login needed
- Any signed-in user
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-63996?
CVE-2026-63996 is a high-severity memory corruption vulnerability in Linux kernel, published on 19 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official 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.
Weakness: CWE-787
Which versions are affected by CVE-2026-63996?
It affects 1 product.
Products include Linux kernel.
How do I fix CVE-2026-63996?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-63996 being exploited?
There is no known exploitation of CVE-2026-63996 in the wild and no public exploit code.
Other vulnerabilities in Linux kernel
Sources
Also known as BELL-CVE-2026-63996, DEBIAN-CVE-2026-63996, GHSA-cwvw-p4x2-27qh, UBUNTU-CVE-2026-63996.