CVE-2026-93067: drm/bridge: tc358767: clamp the reported AUX read size to the request
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: tc358767: clamp the reported AUX read size to the request
tcauxtransfer() clamps an AUX read to the payload limit:
sizet size = mint(sizet, DPAUXMAXPAYLOADBYTES - 1, msg->size);
After the transfer it replaces size with the byte count the controller reports in AUXBYTES:
if (size) size = FIELDGET(AUXBYTES, auxstatus);
AUXBYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tcauxreaddata() reads that many bytes into the 16-byte auxrdata stack buffer, then copies them into the caller buffer. A reported count of 255 makes the read run to 256 bytes and overruns both.
The controller should never report more than it was asked to transfer, so this is defense in depth rather than a live hole. The reported count is only lightly trusted, and the check is cheap. Clamp it back to the request, the same way ti-sn65dsi86 does in commit aca58eac52b8 ("drm/bridge: ti-sn65dsi86: Never store more than msg->size bytes in AUX xfer").
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
drm/bridge: tc358767to a version that resolves this vulnerability.Patch drm/bridge: tc358767: clamp the reported AUX read size to the request - Configuration
In tc_aux_transfer()/tc_aux_read_data(), clamp the reported AUX read size (derived from AUX_BYTES / auxstatus) to the caller/requested msg->size so the controller never reports more bytes than requested; apply the logic analogous to ti-sn65dsi86 (defense in depth rather than a live hole) where the transfer is clamped to msg->size.
tc_aux_transfer() / tc_aux_read_data() AUX read size clamping (reported count) = Clamp reported AUX read size back to the request size (never report more than it was asked to transfer)
Event History
Frequently Asked Questions
Is this considered exploitable during normal operation?
The controller is expected never to report more bytes than were requested, so the issue is described as defense in depth rather than a known live vulnerability. It becomes relevant if the AUX byte-count status is unexpectedly larger than the request.
What condition triggers the memory overrun?
An AUX read is initially limited to the payload limit, but the driver then trusts the controller-reported AUX_BYTES count. A reported count as high as 255 can cause reads beyond the 16-byte auxrdata stack buffer and copies beyond the caller buffer.
What does the fix do?
The fix clamps the controller-reported AUX read count back to the originally requested size. This prevents the driver from reading or copying more data than the request permits.