CVE-2026-68293: Patch Linux mlx5_core EEPROM Crash

The issue is unusually straightforward: the driver had learned that some adapters support 32-dword reads from the MCIA management register—128 bytes—but its internal register layout still reserved only 12 dwords, or 48 bytes, for the returned module data. The driver then accepted a read length up to 128 bytes and copied that amount from the undersized response buffer.

That mismatch produces an out-of-bounds read in kernel memory, not a write into the driver’s buffer. On kernels built with

, the copy is detected and converts an EEPROM query into a kernel BUG. The observed call trace runs from

through the

ethtool path, which means a normal-looking optics or cable diagnostic request can take down a host when the affected capability is present.

NVD published the CVE record on August 10, 2026, drawing its description and affected-version information from kernel.org. At publication, NVD had assigned neither CVSS 4.0 nor CVSS 3.x scoring, and no CWE classification. That absence matters: the record establishes a real memory-safety bug and a reproducible denial-of-service condition, but it does not establish remote exploitation, privilege escalation, information disclosure, or code execution.

The 128-byte read was already allowed by the driver​

The vulnerable logic did not blindly invent a 128-byte request.

explicitly chooses either 12 or 32 dwords based on the adapter’s advertised

feature flag. Older devices use the 48-byte path; capable devices can return 128 bytes.

The contradiction was in the wire-layout definition used to size the request and response arrays.

listed

through

and stopped. Including the MCIA register header, the structure gave the response buffer room for the legacy 12-dword payload, while the runtime logic could request—and later copy—32 dwords.

The resulting failure is a classic interface-contract break inside one driver: the capability check says a device can provide more data, but the C representation of that device register says the data ends much sooner. Bounds-aware builds detect this before the excess source bytes are copied; a build without that checking is still performing an invalid read beyond the end of

.

The kernel fix is correspondingly narrow. It extends the MCIA register layout from 12 payload dwords to 32, so the stack-allocated

and

arrays produced by

match the largest response the driver itself allows. This is not a workaround that lowers the read request back to 48 bytes. Systems retain 128-byte MCIA reads where the hardware advertises support.

Why optics inventory and diagnostics are the trigger​

MCIA is the Mellanox/NVIDIA management register used by the

driver to communicate with pluggable module EEPROMs. Those EEPROMs contain the identification, capability, and diagnostic data reported for SFP, QSFP, QSFP28, and related transceivers or direct-attach cables.

The faulty routine sits beneath both the older module EEPROM query path and the page-based ethtool path. The latter is particularly relevant as Linux networking tooling has moved toward page-aware reads for modern module formats. Requests are broken into supported chunks, with the driver calculating module number, I²C address, page number, and offset before issuing the MCIA register access.

For an affected adapter that advertises 32-dword MCIA capability, a read large enough to use that maximum produces the bad copy. The documented failure is a

buffer-overflow report followed by a kernel BUG, with

named in the trace. That makes the practical availability impact more concrete than the generic phrase “memory corruption”: an administrator, monitoring agent, inventory collector, or automation job that requests module EEPROM data can crash an otherwise healthy network host.

The CVE description does not identify a specific adapter generation, firmware release, optic model, or cable vendor that exposes

. It also does not say that every ConnectX adapter with an

driver is vulnerable in practice. The necessary condition is the combination of vulnerable driver code and an adapter reporting that capability. Administrators should therefore treat the version range as the patch decision, rather than attempting to clear the issue by assuming their installed optics are conventional.

The security boundary remains unproven​

It would be a mistake to report CVE-2026-68293 as a confirmed remote takeover bug. Kernel.org’s advisory text documents an out-of-bounds read and a local crash during an EEPROM operation. It does not provide an attack scenario, a proof of information disclosure, a reliable bypass of kernel memory protections, or evidence that malformed transceiver contents control the copied length.

The copy size comes from the driver’s requested

, capped at 128 bytes when the adapter declares the extended MCIA capability. In other words, the defective condition is not that a module returns an arbitrarily huge record. The driver is asking for a legal 128-byte transaction, then reading 128 bytes from a kernel object built to contain only the old, shorter format.

That technical detail limits what can responsibly be claimed today. The demonstrated outcome on hardened configurations is denial of service. An unfortified build may behave differently because the invalid source read is no longer stopped at the copy site, but the CVE record provides no basis to promise or rank a more serious outcome.

There is another missing detail: neither kernel.org nor NVD says whether an unprivileged local user can reach the relevant ethtool EEPROM operation on a given distribution and configuration. Access control varies with the ethtool interface in use, network namespaces, driver exposure, and local policy. Security teams should not use the lack of a CVSS score as a reason to defer updates, but they also should not turn a verified host-crash condition into a claimed network-exploitable vulnerability without evidence.

Patch levels are clearer than the NVD score​

The kernel.org version data places the introduction at Linux 5.18 and lists four repair points, one per maintained line:

• Linux 6.12.101 contains the fix for the 6.12 long-term branch.
• Linux 6.18.42 contains the fix for the 6.18 stable branch.
• Linux 7.1.6 contains the fix for the 7.1 stable branch.
• Linux 7.2-rc5 contains the upstream mainline fix.

This is useful operationally, but distro package versions still need separate verification. Red Hat Enterprise Linux, Ubuntu, Debian, SUSE, Proxmox, appliance vendors, and cloud images frequently carry security fixes as backports without adopting the upstream version number shown by NVD. Conversely, a package name suggesting a newer kernel line does not prove that its vendor has imported this particular stable commit.

The files to check are

and

. A patched source tree has a 32-dword MCIA payload layout rather than ending at

. For binary-only estate management, the defensible route is the distributor’s security tracker or changelog for CVE-2026-68293, followed by the normal reboot or live-patching process used for the running kernel.

The backports also show this is a maintenance issue, not a one-off experiment confined to next-generation code. The affected functionality entered in Linux 5.18, then stayed present across multiple long-lived kernel lines until the August 2026 repairs landed.

Windows administrators should separate the product names​

Despite the

name, CVE-2026-68293 is a Linux kernel vulnerability. It concerns the in-tree

source and Linux’s ethtool EEPROM query path. It does not, on the available record, apply to NVIDIA’s Windows WinOF-2 driver package or to Windows’ networking stack.

That distinction is easy to lose in mixed Windows/Linux datacenters where the same ConnectX hardware runs on Hyper-V hosts, Linux storage nodes, Kubernetes workers, and bare-metal network appliances. The hardware may be shared across the fleet, but the vulnerable implementation is the Linux driver’s MCIA register layout. Windows hosts should not be marked affected merely because Device Manager shows an NVIDIA/Mellanox adapter.

Linux hosts using these adapters should be patched before scheduled inventory, optics-health polling, or support workflows rely on module EEPROM reads. The correction restores the driver’s promised 128-byte MCIA transaction size without converting that routine diagnostic operation into a kernel crash.