The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade SLES:15.7 kernel-livepatch-6_4_0-150700_53_90-default to version 1-150700.15.3.1 or higher.
Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6_4_0-150700_53_90-default package and not the kernel-livepatch-6_4_0-150700_53_90-default package as distributed by SLES.
See How to fix? for SLES:15.7 relevant fixed versions and status.
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").