CVE-2026-68279
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in how the operating system talks to certain multi-monitor display hubs can let a misbehaving device peek at or crash parts of the system's internal memory.
- Exploitation
- Adjacent Network
- Attacker needs
- Physical Access
- Complexity
- Moderate
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Buffer Overflow
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Unconditional memcpy of attacker-controlled num_bytes from a 256-byte raw message buffer without verifying idx + num_bytes <= curlen, enabling out-of-bounds reads past the received MST sideband payload in drm_dp_sideband_parse_remote_dpcd_read() and drm_dp_sideband_parse_remote_i2c_read_ack().
Why it matters to the business
Systems using DisplayPort MST hubs risk kernel memory disclosure or crashes that can interrupt graphics output, reduce availability of workstations or servers, and require unplanned reboots or driver reloads.
How an attack unfolds
An attacker attaches or emulates a malicious MST hub that returns a remote DPCD or I2C reply containing a num_bytes value larger than the remaining payload length; the kernel parsers then copy past the valid data, reading adjacent kernel memory.
How to fix it
Apply the upstream kernel patch that replaces the two memcpy sites with a combined bounds check (idx + num_bytes > curlen) before any copy; rebuild and deploy the fixed kernel on all affected systems.
How to confirm the fix worked
Confirm the presence of the bounds-check logic in drm_dp_sideband.c, verify the kernel build contains the commit that added the combined length test, and test with a synthetic MST hub that sends oversized num_bytes values.
Typical attack path
- Connect or spoof a DisplayPort MST hub capable of sending crafted sideband replies
- Trigger a remote DPCD read or I2C read transaction from the host
- Supply an oversized num_bytes field that exceeds the actual remaining message length
- Cause the kernel to perform the unchecked memcpy, reading beyond the allocated buffer
- Observe or exfiltrate leaked kernel memory contents or induce a crash
How to detect it
Review kernel logs for oops or warning messages referencing drm_dp_sideband_parse_remote_dpcd_read or drm_dp_sideband_parse_remote_i2c_read_ack; correlate with attachment or removal events of DisplayPort MST devices.
What your security team should do
- Prioritize kernel updates on any system exposing DisplayPort MST ports
- Monitor vendor advisories for backported fixes in distribution kernels
- Disable MST in BIOS or driver settings where multi-monitor topologies are not required
- Add kernel memory corruption and oops logging to existing telemetry pipelines
The record
In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|