Skip to main content

Linux Kernel EUVDEUVD-2026-45568

| CVE-2026-63995 HIGH
2026-07-19 Linux GHSA-g8c6-c8ph-pp93
Information Disclosure Linux
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
7.8 HIGH

Untrusted module data triggers a kernel OOB write reachable only locally via the privileged (CAP_NET_ADMIN) firmware-update path, so AV:L/PR:L with high C/I/A from memory corruption.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:44 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:56 cve.org
HIGH 7.8
CVE Published
Jul 19, 2026 - 14:56 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

ethtool: cmis: validate start_cmd_payload_size from module

The CMIS firmware update code reads start_cmd_payload_size from the module's FW Management Features CDB reply and uses it directly as the byte count for memcpy. The destination buffer is 112 bytes (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious module (or corrupted response) can cause a OOB write later on in cmis_fw_update_start_download().

Let's error out. If modules that expect longer LPL writes actually exist we should revisit.

struct cmis_cdb_start_fw_download_pl's definition has to move, no change there.

AnalysisAI

Out-of-bounds kernel write in the Linux kernel's ethtool CMIS firmware-update path (cmis_fw_update_start_download) lets a malicious or malfunctioning pluggable transceiver module overflow a 112-byte stack/heap buffer by returning an oversized start_cmd_payload_size in its CDB FW Management Features reply. The value is used unchecked as a memcpy byte count, so any attacker able to present a crafted module-or corrupt its CDB response-can corrupt adjacent kernel memory. EPSS is very low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis; the fix simply rejects payload sizes larger than the destination buffer.

Technical ContextAI

The affected code is the kernel's ethtool support for CMIS (Common Management Interface Specification) optical/electrical transceiver modules-the standard governing QSFP-DD, OSFP and similar pluggables. During firmware update, the driver issues a CDB (Command Data Block) query for FW Management Features and reads the module-supplied start_cmd_payload_size field. That value is then passed straight into memcpy targeting a fixed 112-byte buffer (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). This is a classic input-validation failure (CWE-120/CWE-787-class out-of-bounds write, though the CVE lists CWE as N/A): device/firmware-supplied length data is trusted without bounds checking before a copy. Per the CPE data the affected component is the mainline Linux kernel (cpe:2.3:a:linux:linux). Because CMIS module responses are read over the module's two-wire/MCU management interface, the untrusted input originates from hardware plugged into the host, not from the network.

RemediationAI

Patch available per vendor advisory: upgrade to a fixed Linux kernel build-mainline 7.1 or the patched stable releases 7.0.12, 6.18.35, or 6.12.93 (or your distribution's kernel that incorporates commit 63112b451546 / 0696709e951b / a46340da0038 / 12c2496a71f8), which makes the code error out when start_cmd_payload_size exceeds the 112-byte destination buffer. Apply the git.kernel.org stable commits above if you build your own kernel. Where immediate patching is not possible, the practical compensating control is to avoid initiating CMIS transceiver firmware updates (the only path that reaches the vulnerable memcpy) and to restrict physical access so untrusted/unknown optical modules cannot be inserted into managed hosts; the trade-off is that legitimate module firmware updates must be deferred until patched. Restricting CAP_NET_ADMIN also limits who can trigger the ethtool firmware-update operation.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-45568 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy