CVE-2026-68235 Crashes Linux AMDGPU on DCE8 DisplayPort MST

The National Vulnerability Database entry was published on August 11, 2026, but its page was unavailable at publication time behind a Cloudflare 502 error. That failure leaves the public record without the practical details administrators normally need from NVD: no usable CVSS score, no enumerated affected kernel versions, no CPE product list, and no remediation guidance. The Linux kernel mailing-list record fills in much of that missing technical context—and narrows the real-world risk considerably.

According to the AMD GPU mailing list submission by Andriy Korud, the crash was reproduced on an AMD Radeon R7 260X, a Bonaire-based card using the DCE8 display engine. The trigger was specific: connect two displays through a DisplayPort MST daisy chain, then either boot with the second screen connected or hot-plug it. On the affected kernel, the atomic display commit can call through a null function pointer and produce a kernel oops.

For users of contemporary Radeon hardware, single-monitor setups, HDMI-only configurations, or standard DisplayPort connections without MST, this CVE does not describe the failure mode they need to chase. For the much smaller group maintaining Bonaire-era systems with daisy-chained DisplayPort monitors, docks, or MST hubs on Linux, it is a stability bug that can take down the graphics session—and potentially the system—during display configuration changes.

The failure is an encoder-selection bug​

The defect is in

, a resource-allocation routine in the AMD Display Core driver. DCE8-class hardware has a mix of display-stream encoders: digital encoders for DisplayPort-style output and an analog DAC encoder intended for legacy analog output.

When Linux assigns an encoder to the first DisplayPort MST stream, it normally obtains the appropriate digital resource. The trouble begins when the driver configures a second MST stream and its preferred digital encoder is already occupied. The fallback logic can select the first free entry in the resource pool instead.

On the Radeon R7 260X configuration tested by Korud, that spare entry can be the analog DAC encoder. It does not implement the DisplayPort callback

. The later display-enable path,

, assumes that callback exists and dereferences it. The result is a kernel null-pointer fault during the atomic modeset.

This is why “two monitors” alone is an incomplete description of the bug. The vulnerable sequence needs several conditions at once:

• The system must use the Linux amdgpu display driver on hardware covered by the DCE8-style resource code, with Bonaire confirmed by the reporter.
• The displays must use DisplayPort MST, such as a daisy chain or an MST hub that presents multiple downstream screens over one DisplayPort link.
• The driver must need a fallback encoder allocation for a second stream.
• That fallback must encounter the analog encoder before a usable digital choice.

The combination is important for triage. A fleet running new RDNA Radeon cards may contain machines with several DisplayPort monitors and still be outside this exact code path. Conversely, a lab or industrial workstation retaining Radeon R7 260X-class cards can be exposed even though the hardware is old enough to fall outside normal desktop refresh cycles.

The upstream fix rejects an invalid fallback​

The patch submitted to the AMD GPU mailing list makes a compact but targeted change. Before accepting a free stream encoder for a DisplayPort signal, the code now checks that the encoder has a function table and a

implementation. An analog or otherwise non-DisplayPort-capable encoder is skipped.

The patch also replaces a narrower condition that tested the physical connector signal with

. That distinction is material in MST handling: the resource decision is being made for an individual logical display stream, not merely the physical parent connector. Linux’s DRM documentation describes DP MST as a configuration in which multiple display streams share one physical DisplayPort connection, with separate MST-oriented encoder objects used to represent those streams.

The original submission reported that the issue had been seen since Linux 6.19 and reproduced on kernel 7.1.3. With the patch applied, Korud reported stable dual-monitor operation in the same R7 260X MST setup. That is useful confirmation that the guard fixes the observed crash, but it is still a single hardware report rather than a broad compatibility matrix.

AMD maintainer Alex Deucher replied on July 13 that he had manually cleaned up the email-damaged patch and asked the contributor to use

for future submissions. That exchange matters more than its mailing-list housekeeping suggests: it shows the fix was not left as an unreviewed report. The change subsequently appeared in the upstream Linux source tree under the same description, meaning the correction has entered the normal upstream kernel flow.

The timing points to Linux 6.19-era display changes​

There is a useful clue in the history of this code. Earlier 2026 work changed DCE100 resource selection so that analog stream encoders would only be chosen when the hardware actually had an analog engine. That work was upstreamed and reviewed for the Linux 6.19 stable series.

CVE-2026-68235’s reporter says the MST crash was observed starting with Linux 6.19. The new patch does not include a formal

tag naming the precise introducing commit, so it would be irresponsible to present the earlier analog-encoder change as conclusively responsible. But the timing and the common function strongly indicate that the issue emerged from the same area of legacy encoder-selection logic.

That also explains why this is a problem on DCE8 rather than a sweeping AMDGPU failure. The patch is limited to

, which serves an older display-engine family. Modern Radeon generations use different display-engine code and resource models. The NVD outage currently prevents an authoritative public affected-version table, but the upstream patch’s narrow placement argues against treating every Linux system with an AMD GPU as affected.

Administrators should verify the running kernel, not the CVE page​

The immediate operational step is to identify Linux systems that combine old Bonaire-era Radeon hardware with DP MST. On a suspected host,

can identify the GPU and driver in use, while

establishes the actual kernel version. Desktop-support teams should also ask whether a dock, MST hub, or monitor daisy chain is in use; an ordinary second monitor on a second physical output does not necessarily exercise this defect.

Because the issue is a kernel-driver crash, the durable remedy is a kernel package incorporating the upstream patch. Users should take their distribution’s normal kernel update once it has backported the change, reboot into the updated kernel, and then test the exact connection pattern that caused the failure: cold boot with both panels attached, hot-plug of the second display, suspend/resume, and repeated monitor enable/disable cycles.

Until a packaged fix is available, the practical mitigation is to avoid the triggering topology. Connect displays through separate physical GPU outputs where possible, disconnect the secondary MST monitor before booting, or disable the second display before hot-plugging hardware. Rebuilding a production kernel solely for this defect is hard to justify for most organizations unless the affected hardware and display topology are essential.

The conspicuous gap is distribution status. As of August 11, 2026, the public NVD record was inaccessible and no distribution advisory surfaced in the available reporting to identify fixed package builds. That means the CVE number is useful for tracking and ticketing, but it is not yet a reliable patch-management identifier. For now, the upstream Linux commit is the real technical boundary: organizations with DCE8-era AMD systems and DisplayPort MST should watch their kernel changelogs for this exact

encoder-selection fix, rather than assuming that a generic AMDGPU update has addressed it.