CVE-2026-64219: drm/amd/display: Validate payload length and link_index in dc_process_dmub_aux_transfer_async
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Validate payload length and linkindex in dcprocessdmubauxtransferasync
[Why&How] dcprocessdmubauxtransferasync() copies payload->length bytes into a 16-byte stack buffer (dpaux.data[16]) guarded only by an ASSERT(), which is a no-op in release builds. If a caller ever passes length > 16 this results in a stack buffer overflow via memcpy.
Additionally, linkindex is used to dereference dc->links[] without bounds checking against dc->linkcount, risking an out-of-bounds access.
Replace the ASSERT with a hard runtime check that returns false when payload->length exceeds the destination buffer size, and add a bounds check for linkindex before it is used.
(cherry picked from commit ba4caa9fecdf7a38f98c878ad05a8a64148b6881)
Affected Software
Event History
Frequently Asked Questions
What attacker access is required to exploit this issue?
Exploitation requires local access, low-level privileges, and high attack complexity. No user interaction is required.
What invalid inputs can trigger the vulnerable behavior?
A caller must supply a payload longer than 16 bytes to overflow the stack buffer, or provide a link_index outside the valid dc->links[] range to cause an out-of-bounds access.
Do release-build assertions protect against the overflow?
No. The existing ASSERT() check is a no-op in release builds, so it does not prevent an oversized payload from reaching memcpy.
What validation does the fix add?
The resolved code rejects payloads that exceed the destination buffer size by returning false and verifies link_index against dc->link_count before dereferencing the link array.