CVE-2026-68278

What it actually does

Three buffer handling flaws in drm_dp_sideband_append_payload allow out-of-bounds reads and writes when processing device-supplied sideband reply headers: zero-length msg_len triggers u8 underflow and 255-byte accesses beyond chunk[48] and into msg[], curchunk_len up to 63 exceeds the 48-byte chunk buffer during multi-iteration assembly, and unbounded accumulation can overflow the 256-byte msg[] into adjacent structures.

Why it matters to the business

Linux systems using DisplayPort MST displays face risk of kernel crashes or potential code execution from a physically connected device, which can disrupt graphics workloads, require reboots, and increase operational overhead until kernels are updated.

How an attack unfolds

An attacker with physical access or control of a DP MST device crafts a sideband reply message containing either msg_len=0 or a curchunk_len value that exceeds buffer limits; the kernel's accumulation loop then performs unchecked memcpy and CRC reads that corrupt memory and may be leveraged for denial of service or further exploitation.

How to fix it

Upgrade the Linux kernel to a version containing the fix for drm_dp_sideband_append_payload buffer length validation; rebuild and deploy the updated kernel image on all affected systems, then reboot.

How to confirm the fix worked

Confirm the presence of the corrected drm_dp_sideband_append_payload implementation that enforces non-zero curchunk_len, bounds checks against the 48-byte chunk array, and validates total length against the 256-byte msg buffer; test with a DP MST device that can emit edge-case sideband replies.

Typical attack path

1. Gain physical or emulated connection to a target system's DisplayPort MST port
2. Transmit a forged sideband reply header with msg_len=0 or maximum 6-bit length values
3. Trigger repeated payload append operations that execute the underflow and overflow paths
4. Observe or exploit resulting memory corruption for crash or code execution

How to detect it

Review kernel logs for drm_dp_sideband or msg_data_crc4 related oops/panic entries; correlate with insertion of unknown DP MST devices in system or udev logs; no network or file-based indicators are expected.

What your security team should do

• Apply the kernel fix as soon as a stable release containing the patch becomes available
• Restrict physical access to systems with exposed DisplayPort MST ports until updated
• Include kernel oops and drm stack traces in existing crash-monitoring pipelines