CVE-2026-63995 Overview
CVE-2026-63995 is an out-of-bounds write vulnerability in the Linux kernel's ethtool Common Management Interface Specification (CMIS) firmware update code. The flaw resides in the CMIS firmware update path, where the kernel reads start_cmd_payload_size from a module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. Because the destination buffer is fixed at 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8), a malicious or corrupted module response can trigger an out-of-bounds write in cmis_fw_update_start_download(). The issue affects local attack surfaces requiring low privileges.
Critical Impact
A malicious optical transceiver module or a corrupted CDB response can trigger kernel heap corruption, leading to potential privilege escalation, kernel memory disclosure, or denial of service.
Affected Products
- Linux kernel versions containing the CMIS firmware update code prior to the referenced stable commits
- Systems using ethtool with CMIS-compliant optical modules (QSFP-DD, OSFP, and similar)
- Distributions shipping affected kernel builds until backports are applied
Discovery Timeline
- 2026-07-19 - CVE-2026-63995 published to NVD
- 2026-07-20 - Last updated in NVD database
Technical Details for CVE-2026-63995
Vulnerability Analysis
The vulnerability exists in the Linux kernel's CMIS firmware update handling within the ethtool subsystem. CMIS is the standard interface used to manage pluggable optical transceivers. During a firmware update sequence, the kernel queries the module for its FW Management Features via a CDB (Command Data Block) reply. The response includes a start_cmd_payload_size field intended to describe the maximum payload the module accepts for the start-download command.
The kernel trusts this value without bounds checking. It passes the attacker-controlled size directly into a memcpy call inside cmis_fw_update_start_download(). The destination is a fixed-size Local Payload (LPL) buffer of 112 bytes, calculated as ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8. Any module reply reporting a larger value causes the copy to write past the buffer.
Root Cause
The root cause is missing input validation of externally-supplied length data from a hardware peripheral. The vulnerability falls under Out-of-Bounds Write and Improper Input Validation. The kernel treats the module's CDB reply as trusted input, yet a compromised or crafted module can return arbitrary values. The upstream fix rejects updates when start_cmd_payload_size exceeds the maximum allowed LPL length rather than truncating or attempting to accommodate the larger value.
Attack Vector
Exploitation requires local access with the ability to initiate an ethtool firmware update against a CMIS module, or the presence of a malicious or tampered pluggable transceiver. An attacker with control over the module firmware, or physical access to insert a rogue module into a server or switch host, can trigger the out-of-bounds write during a firmware update flow. The write occurs in kernel context and corrupts adjacent kernel memory. Depending on heap layout, this can be leveraged for local privilege escalation or a denial-of-service condition. See the Kernel Git Commit a46340d and Kernel Git Commit 0696709 for the corrective validation logic.
Detection Methods for CVE-2026-63995
Indicators of Compromise
- Unexpected kernel oops or panic traces referencing cmis_fw_update_start_download or ethtool_cmis_cdb symbols.
- Kernel log entries showing failed or aborted CMIS firmware updates on transceiver ports.
- Presence of unauthorized or unrecognized pluggable optical modules in host inventory audits.
Detection Strategies
- Monitor dmesg and journald for ethtool CMIS-related errors, warnings, or KASAN reports indicating out-of-bounds writes.
- Audit the running kernel version against distribution advisories and confirm whether the fix commits have been backported.
- Track invocations of ethtool --flash-module-firmware and correlate them with the operator, host, and module serial number.
Monitoring Recommendations
- Forward kernel logs to a centralized logging platform and alert on stack traces mentioning CMIS or ethtool CDB functions.
- Maintain a hardware inventory of installed transceivers and flag modules that were not sourced through approved supply channels.
- Enable KASAN or similar memory sanitizers in lab and pre-production kernels to catch OOB writes before promotion to production.
How to Mitigate CVE-2026-63995
Immediate Actions Required
- Apply the upstream kernel patches referenced in the stable commits to all affected hosts and reboot into the patched kernel.
- Restrict CAP_NET_ADMIN and root access on systems with CMIS transceivers to trusted operators only.
- Defer any non-essential CMIS firmware update operations until the patched kernel is deployed.
- Audit installed pluggable modules and remove any of unknown or untrusted provenance.
Patch Information
The vulnerability is resolved across multiple stable branches. Refer to the following upstream commits: Kernel Git Commit a46340d, Kernel Git Commit 0696709, Kernel Git Commit 12c2496, and Kernel Git Commit 63112b4. The fix validates start_cmd_payload_size against ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8 and errors out if the module-supplied value exceeds the destination buffer.
Workarounds
- Avoid executing ethtool --flash-module-firmware on hosts running unpatched kernels.
- Enforce strict physical-access controls and supply-chain vetting for pluggable optical transceivers.
- Where feasible, use kernel builds with KASAN enabled in test environments to detect exploitation attempts against the affected code path.
# Verify the running kernel and confirm the CMIS fix is present
uname -r
git log --oneline | grep -E "cmis|start_cmd_payload_size"
# Restrict who can invoke ethtool firmware flashing
chmod 750 /usr/sbin/ethtool
auditctl -w /usr/sbin/ethtool -p x -k ethtool_exec
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

