CVE-2026-68293

CVE-2026-68293 is a buffer overflow in the mlx5 driver's MCIA (Management Communication Interface A) path. The function mlx5_mcia_max_bytes() returns a hardware-dependent maximum size—potentially 32 dwords—but the destination struct mlx5_ifc_mcia_reg_bits defines only 12 dwords of storage. When code checks the capability flag, clamps the read size to the returned maximum, and performs the memcpy, it silently writes past the struct boundary. The overflow only manifests under specific conditions: FORTIFY_SOURCE enabled in the build, or hardware with the 32-dword capability present. Without those conditions, the vulnerability remains latent. The critical failure here is API design, not implementation. A developer calling mlx5_mcia_max_bytes() receives a legitimate ceiling value and has no signal—type-level, compile-time, or even documentary—that the destination struct cannot hold it. The function returns an int; the struct defines 12 dwords; there is no contract linking them. The code passes every logical check: capability verified, size clamped, memcpy executed. The bug surfaces only when memory safety tools are enabled or when specific hardware makes the mismatch fatal. This pattern has historical precedent. Capability-query functions returning variable bounds paired with fixed-struct layouts have produced vulnerabilities in USB descriptors, PCI capability chains, and network driver interfaces across kernel generations. The mlx5 driver is not an isolated case—it is one instance of a structural decoupling that persists because kernel capability negotiation treats hardware limits as advisory rather than contractual. No compile-time mechanism enforces that the value returned by mlx_mcia_max_bytes() can actually fit in the struct it populates. The exposure is amplified through ethtool, which exposes this code path to user-space. Every diagnostic script, NMS agent, and automated inventory tool that queries mlx5 hardware through ethtool becomes a potential trigger vector. The overflow manifests as a read past buffer bounds—the data is corrupted before validation can intervene. The immediate fix extends the struct to 32 dwords, which resolves the symptom. However, this creates technical debt: any code depending on the exact 12-dword layout becomes fragile, and the underlying API decoupling remains. Future capability flags that expand register sizes will encounter the same trap unless the kernel adopts a norm where capability functions carry compile-time-verifiable size bounds tied to their destination structs—something the kernel currently lacks despite decades of this failure mode recurring.

Reviewed through automated stages and approved by a human before publication.