CVE-2026-93067 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: tc358767: clamp the reported AUX read size to the request
tc_aux_transfer() clamps an AUX read to the payload limit:
size_t size = min_t(size_t, DP_AUX_MAX_PAYLOAD_BYTES - 1, msg->size);
After the transfer it replaces size with the byte count the controller reports in AUX_BYTES:
if (size) size = FIELD_GET(AUX_BYTES, auxstatus);
AUX_BYTES is GENMASK(15, 8), so it can be up to 255. Nothing clamps it back to the request. tc_aux_read_data() 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").
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified within the Linux kernel's DRM bridge driver for the Toshiba TC358767 chip represents a classic buffer overflow scenario rooted in insufficient validation of external hardware inputs. The core issue resides in the tc_aux_transfer function, which manages Auxiliary Channel (AUX) transactions used primarily for DisplayPort communication such as reading EDID data or handling DPCD registers. During an AUX read operation, the driver initially calculates a safe transfer size by clamping the requested message size against the maximum payload limit defined by DP_AUX_MAX_PAYLOAD_BYTES minus one. This initial step correctly limits the intended scope of the transaction to prevent excessive memory allocation or processing at the outset. However, the logic flaw emerges after the hardware controller completes the physical data transfer and returns a status register containing AUX_BYTES, which indicates the actual number of bytes received from the device.
The critical technical flaw is that while the driver uses this returned byte count to update its internal size variable for subsequent operations, it fails to re-validate or clamp this value against the original request size or the fixed-size stack buffer allocated for the operation. The AUX_BYTES field in the status register is defined as a GENMASK from bit 8 to bit 15, allowing values up to 255. When the driver proceeds to read data using tc_aux_read_data, it utilizes this unclamped value to determine how many bytes to copy into auxrdata, which is a fixed-size stack buffer of only sixteen bytes. If the hardware controller reports a byte count near the maximum limit due to internal errors, misconfiguration, or malicious behavior in emulated environments, the read operation will attempt to write up to 256 bytes into this 16-byte buffer. This results in a severe stack-based buffer overflow that corrupts adjacent memory on the kernel stack, potentially overwriting return addresses, saved frame pointers, and other critical control data.
From an operational impact perspective, while the immediate exploitation of this vulnerability may be constrained by the specific hardware context where it occurs, the risk remains significant for system stability and security integrity. In a local physical access scenario or within virtualized environments that emulate DisplayPort controllers, an attacker could potentially trigger malformed AUX responses to induce stack corruption. This corruption can lead to kernel panics causing denial of service conditions, or in more complex exploitation chains involving information disclosure via stack dumps, it might reveal sensitive kernel memory contents. Although the TC358767 is a physical hardware component and direct remote exploitation over network vectors is not applicable here, the principle of defense-in-depth dictates that drivers must never trust unvalidated output from peripheral devices as authoritative for buffer sizing decisions without independent verification against internal constraints.
To mitigate this vulnerability, the driver logic must be updated to clamp the reported byte count back to the original request size before performing any memory copy operations. This approach aligns with established best practices seen in similar drivers such as ti-sn65dsi86, which explicitly ensures that no more than msg->size bytes are stored during AUX transfers. By enforcing this constraint, the driver guarantees that even if the hardware reports an anomalously high byte count due to internal faults or adversarial emulation, the memory access remains bounded by the initially requested and validated size limit. This fix not only resolves the immediate buffer overflow risk but also reinforces the robustness of the DRM subsystem against future edge cases involving peripheral communication protocols. The remediation involves adding a simple conditional check after retrieving AUX_BYTES to ensure it does not exceed msg->size, thereby maintaining strict bounds on stack usage and preventing memory corruption vulnerabilities associated with untrusted hardware feedback loops.