Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
Linux kernel < 6.6.157.1-1 may overrun memory
published 1 month ago
Summary
The core operating system code (Linux kernel) versions older than 6.6.157.1-1 contain a flaw in the handling of a display‑bridge function. It can copy more data than the temporary buffer can hold, potentially causing a crash or allowing unauthorized code execution. Install the latest kernel update that includes the fix to prevent this issue.
What to do
- Update kernel to version 6.6.157.1-1.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| Azure Linux:3 | azure | kernel | <= 6.6.150.1-1 |
| Azure Linux:3 | – | kernel |
<= 6.6.152.1-1 < 6.6.157.1-1 Fix: upgrade to 6.6.157.1-1
|
Original advisory text
CVE-2026-93067 affecting package kernel for versions less than 6.6.157.1-1
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").
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").
References
Timeline
Published17 Sep 2026
Updated2 Oct 2026
First seen23 Sep 2026
Sources
AZL-102731 · OSV
Track software like this
Free during beta