CVE-2026-68278: Patch Linux DP MST Buffer Overflows

The Linux kernel CVE record, now mirrored by NVD, identifies

as affected and lists fixed upstream release lines including Linux 6.6.148, 6.12.101, 6.18.42, 7.1.6, and the Linux 7.2 development tree. The patch was included in the DRM pull request for Linux 7.2-rc1 and has also appeared in downstream SUSE kernel update notes. NVD has not assigned a CVSS score as of August 11, 2026.

For administrators, the immediate action is straightforward: update to the current vendor kernel package if the system uses DisplayPort MST hardware. That includes many USB-C and Thunderbolt docks, DisplayPort hubs, monitors connected in a daisy chain, and some multi-display KVM arrangements. This is a Linux graphics-driver issue, not a flaw in Windows’ native graphics stack; ordinary Windows systems are not directly exposed by this CVE simply because they use DP MST displays.

The actual flaw is in device-supplied sideband replies​

DisplayPort MST lets a source device drive multiple displays through one DisplayPort connection. The protocol relies on sideband messages to discover ports, allocate display bandwidth, and communicate with branch devices such as docks, hubs, and daisy-chain-capable monitors.

Linux’s DRM DisplayPort MST helper receives those replies in pieces, assembling each chunk into a 48-byte temporary buffer and then copying completed content into a larger 256-byte message buffer. The new patch adds checks before both stages: it rejects a chunk length greater than the temporary buffer and rejects a completed chunk if copying it would exceed the accumulated-message buffer.

Those are meaningful checks because the reply header exposes a six-bit

field, permitting values through 63, while the local

array holds only 48 bytes. Without validation, a device-controlled value above 48 could cause the receive loop to copy more data than

can hold. The patch also ensures that repeatedly accepted chunks cannot grow

beyond 256 bytes.

The patch’s practical behavior is to fail construction of the sideband message rather than continue processing malformed data. Linux’s surrounding MST code logs a sideband-message build failure, so the likely visible symptom of a rejected malformed reply is a dock, hub, or display topology failing to enumerate correctly, rather than a transparent recovery.

CVE-2026-68278 repeats a vulnerability fixed in 2024​

The new CVE description says a branch device can set

to zero, leading to an eight-bit underflow and a 255-byte read and copy. That was a real historical condition, but it is not a newly reachable path in supported kernels that include the 2024 fix.

CVE-2024-56616 documented the same failure in the same function: a zero-length MST sideband body could result in an index of

against the 48-byte chunk buffer and an effectively unbounded copy into the 256-byte message array. The fix for that CVE changed the earlier message-header decoder to reject body lengths below one byte before the receive state is set up.

That sequencing matters. A reply with

is rejected by

before it can be assigned to

and passed into

. The new patch’s

check is therefore sensible defense in depth, but calling the zero-length condition a newly exploitable third bug overstates the present exposure.

The kernel mailing-list patch itself makes the same three-part claim carried into CVE-2026-68278. An automated review posted to the DRM review list correctly noted that the zero-length path had already been blocked by the earlier decoder validation. The reviewer’s provenance is not a substitute for maintainer analysis, but the conclusion is independently verifiable against the prior CVE’s fix description and the control flow in the affected code.

The material security fix in CVE-2026-68278 is the new enforcement of the 48-byte per-chunk limit and the 256-byte accumulated-message limit. The zero-length guard is a belt-and-suspenders addition to a condition upstream had already addressed.

The threat model is physical display hardware, not a remote browser exploit​

The CVE record says the issue is reachable by a DP MST device able to forge sideband replies over a physical connection. In practice, that narrows the attack surface substantially compared with a network-facing kernel parser: an attacker needs control of, or the ability to impersonate, a DisplayPort MST branch device.

That can mean a malicious or compromised dock, a hostile DP hub, an unusual display adapter, or a monitor/branch device with compromised firmware. It could also matter in environments where users connect untrusted peripherals to developer workstations, shared lab systems, kiosk hardware, or privileged Linux endpoints.

It does not mean every external monitor is an MST attack vector. A conventional single DisplayPort monitor normally does not create an MST topology. The vulnerable code is exercised when the kernel communicates with MST branch hardware, which is commonly present when one physical DP or USB-C display path fans out to several outputs.

There is also no evidence in the published record of exploitation in the wild, no public proof-of-concept, and no NVD severity assessment yet. Administrators should avoid turning that absence into an assurance: kernel memory-safety bugs in device-parsing paths can produce crashes and memory corruption even where reliable code execution has not been demonstrated publicly.

The version metadata should be read as fixed release floors​

The Linux kernel CVE entry marks the driver as affected beginning with Linux 3.17, then identifies clean upstream versions in each maintained line: 6.6.148, 6.12.101, 6.18.42, and 7.1.6. It also identifies the fix as present from Linux 7.2-rc1 onward.

That does not mean a distribution shipping an older-looking kernel package is automatically vulnerable. Enterprise distributions routinely backport security fixes without adopting the upstream version number. Conversely, a locally compiled kernel based on an older source tree remains exposed unless it contains the relevant patch or an equivalent downstream backport.

For systems where the exact vendor status is unclear, check the distribution’s kernel changelog or security tracker for the patch title:

• drm/dp/mst: fix buffer overflows in sideband chunk accumulation

SUSE’s published kernel update material already lists that change, demonstrating that at least one major downstream has picked it up. No broad cross-distribution remediation table accompanied the CVE publication, however, so Fedora, Ubuntu, Debian, Red Hat, and appliance-kernel users should treat package status as distribution-specific rather than infer coverage from the upstream version list.

What Windows users running Linux should do​

For dual-boot PCs, the relevant question is the kernel booted into Linux, not the hardware’s Windows driver version. A machine can be fully patched on Windows and still run an affected Linux kernel when booted into a distribution with an older package.

For WSL 2 users, the ordinary GUI and display path is virtualized rather than Linux directly parsing the host’s physical DisplayPort MST replies. The CVE therefore does not map cleanly onto the normal WSL desktop threat model. The concern is stronger for bare-metal Linux installations and Linux hosts that manage physical dock and display hardware directly.

The immediate operational priority is modest but specific: apply your distribution’s current kernel update on Linux endpoints that use MST-capable docks, hubs, or daisy-chained displays, then reboot into it. The important correction is equally specific: patch for the two real buffer-boundary failures, but do not mistake CVE-2026-68278’s recycled zero-length scenario for a newly reopened version of CVE-2024-56616.