CVE-2026-68120

The CVSS 7.5 on CVE-2026-68120 badly misrepresents the actual risk profile, but the more important issue is what this CVE reveals about a growing class of vulnerabilities: driver-level workarounds for hardware defects that insert trust boundaries where they never belonged. The core issue is a Realtek NIC transmit hang bug triggered by malformed outbound packets—specifically IPv4 non-initial fragments and short UDP packets to PTP ports 319/320. The Linux driver responds by validating packets before transmission and dropping those that would trigger the hardware failure. This is not a traditional software vulnerability; it's a correctness layer over broken silicon. The exploitation path requires either local privilege (to control outbound packet construction) or cooperation from a transmission endpoint—fundamentally different from a remote trigger. The EPSS score of 0.00446 is a more honest assessment. But the deeper concern is what the workaround itself introduces. The driver now performs IPv4 fragment inspection, UDP port validation, and minimum-length checks at transmission time—logic that has never existed at this layer and was never audited for parsing vulnerabilities. The IPv6 exclusion is the most telling detail: the hardware stops parsing when it encounters a Fragment Header, so IPv6 fragments bypass the problematic code path entirely. This wasn't documented in errata—the driver developers reverse-engineered it through trial and error. What's the confidence interval on that behavior for tunneled IPv6, VLAN-tagged frames, or encapsulation scenarios? The CVE description doesn't say, and that's the gap. Operationally, verify whether your affected systems are running a driver version with this workaround (check the git history for the filtering logic). If you're maintaining custom driver branches or vendor kernels, audit the workaround code itself for off-by-one conditions in length validation and buffer boundary handling in the padding logic—the same patterns seen in Intel speculative execution mitigations and AMD fTPM workarounds. The pattern is legible: hardware defect creates driver workaround, workaround introduces protocol inspection at an unusual layer, that inspection logic becomes the vulnerability. The Linux driver contains the explicit IPv6 exclusion comment—find that same artifact in any driver variants you're shipping. The real exposure isn't the hardware bug; it's the thousands of lines of workaround logic propagating across the driver ecosystem with minimal re-audit.

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