Cloudanix VulnDB

CVE-2026-63996

High · 7.8

CVSS

7.8

EPSS

0.1%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in handling responses from certain network plug-in modules could let an attacker who already has access to the machine corrupt system memory and potentially take control.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Theoretical
Impact
Full Compromise
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Insufficient length validation in cmis_cdb_process_reply allows a reply longer than the caller-expected rpl_exp_len, resulting in out-of-bounds writes when the payload is cast to fixed-layout structs by callers such as cmis_cdb_validate_password, cmis_cdb_module_features_get and cmis_fw_update_fw_mng_features_get.

Why it matters to the business

Local compromise of systems that use SFP/CMIS modules can lead to kernel memory corruption, privilege escalation, denial of service or data integrity loss on servers and network appliances; urgency is low given the theoretical nature of malicious hardware and the absence of known exploitation.

How an attack unfolds

An attacker with local access inserts or emulates a buggy or malicious SFP module that returns an oversized CDB reply; ethtool processes the reply without checking the actual length against the expected size, writing beyond allocated buffers and corrupting kernel memory.

How to fix it

Update the Linux kernel to a version that contains the fix requiring exact CDB reply length; rebuild and reboot any affected systems; where immediate patching is impractical, restrict untrusted SFP modules and limit ethtool access via policy.

How to confirm the fix worked

Verify the running kernel contains the commit that adds the exact-length check and warning in cmis_cdb_process_reply; inspect source or binary for the new length comparison before the payload cast; test with a deliberately oversized reply to confirm rejection.

Typical attack path

  1. Obtain local access or the ability to present a crafted SFP module to the target host
  2. Trigger ethtool CMIS CDB operations that invoke cmis_cdb_process_reply with a non-zero rpl_exp_len
  3. Supply a reply whose rpl_len exceeds the expected size
  4. Trigger out-of-bounds write into adjacent kernel structures
  5. Leverage resulting memory corruption for privilege escalation or denial of service

How to detect it

Search kernel logs for new warning messages emitted when an oversized CDB reply is received; correlate ethtool invocations with unexpected crashes or memory-corruption oops; examine audit logs for unusual SFP insertion events followed by privileged process activity.

What your security team should do

  • Prioritize kernel updates on any host that exposes ethtool CMIS interfaces to pluggable optics
  • Monitor upstream stable and distribution kernels for the back-ported patch
  • Apply least-privilege controls around ethtool and SFP hot-plug events
  • Reassess after 30 days if EPSS or public exploit code increases

The record

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.

Affected packages

Ecosystem Package Introduced Fixed