Cloudanix VulnDB

CVE-2026-93067

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small error in how the Linux kernel reads data from certain display hardware could let it grab too many bytes and crash or corrupt memory, though normal hardware behavior stops this from happening.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Full Compromise
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Out-of-bounds read in tc_aux_read_data caused by replacing the requested size with an un-clamped value from AUX_BYTES (up to 255) when copying into a 16-byte auxrdata stack buffer.

Why it matters to the business

Rare display driver instability or limited memory corruption on systems using the tc358767 bridge; low practical risk because the hardware controller is expected to respect the requested size.

How an attack unfolds

An attacker with the ability to influence the AUX status register would cause the driver to report a byte count larger than the original request, resulting in the kernel reading past the end of the stack buffer during AUX transfers.

How to fix it

Apply the upstream fix that re-clamps the size returned from AUX_BYTES to the original msg->size before copying data, matching the approach used in ti-sn65dsi86.

How to confirm the fix worked

Inspect the tc_aux_transfer function to confirm that size is clamped with min_t against the original request after reading AUX_BYTES and before calling tc_aux_read_data.

Typical attack path

  1. Locate a Linux system exposing the tc358767 DRM bridge driver
  2. Trigger an AUX read operation via display or DP link management
  3. Manipulate AUX_BYTES to return a count exceeding the request size
  4. Observe kernel stack overflow during tc_aux_read_data copy

How to detect it

Search kernel logs and crash dumps for tc358767 or drm/bridge AUX transfer faults; examine stack traces showing overruns in auxrdata.

What your security team should do

  • Upgrade to a kernel containing the AUX size clamp commit
  • Audit custom display bridge drivers for similar missing clamps
  • Monitor kernel oops logs for tc358767 stack overruns

The record

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").

Affected packages

Ecosystem Package Introduced Fixed