CVE-2026-63996 ethtool: cmis: require exact CDB reply length

High 7.8 Published Updated

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.

All Linux kernel vulnerabilities

Sources

Also known as BELL-CVE-2026-63996, DEBIAN-CVE-2026-63996, GHSA-cwvw-p4x2-27qh, UBUNTU-CVE-2026-63996.

Is CVE-2026-63996 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free