Description

In the Linux kernel, the following vulnerability has been resolved: drm/connector/hdmi: Fix out of bounds memory read A helper function was copying a given audio infoframe into the connector's copy but using the size of the destination (a generic target, sized to accept many different data blocks) not the source (a very specific type of data block). Thus, it was copying 60 bytes of data from a 28 byte allocation. Fix that by using the source size instead, together with a build bug on the source size actually being smaller than the destination. I hit this running KUnit tests under KASAN (while debugging something else entirely). In the real world, it seems unlikely to cause an actual problem. It is a read not a write so it can't corrupt any memory. However, it could potentially fall off the end of a page and cause an accvio bug.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-03T13:06:14.520Z",
  "pubdate": "2026-09-03T13:06:14.520Z",
  "executiveSummary": "This vulnerability is an out-of-bounds memory read occurring within the Linux kernel's DRM (Direct Rendering Manager) HDMI connector subsystem. The flaw arises from an incorrect size calculation during an audio infoframe memory copy operation, where the implementation utilizes the destination buffer size rather than the source buffer size. This results in the kernel reading beyond the allocated memory boundaries of the source data block.\nThe vulnerability is categorized as an out-of-bounds read, potentially leading to kernel memory disclosure or system instability due to a kernel panic (access violation). While the current implementation primarily poses a risk of memory leakage, the impact is mitigated by the nature of the operation, which is a read-only process that precludes direct memory corruption or code execution.\nThe flaw affects Linux kernel systems utilizing HDMI connector audio infoframe handling. Exploitation requires no specific authentication or privileges, but it does require local access or a mechanism to trigger the specific DRM ioctl or connector logic that initiates the flawed audio infoframe copy. The risk is considered moderate due to the potential for crash-based denial of service and information leakage through memory inspection.",
  "technicalDetails": "The vulnerability resides in the drm/connector/hdmi component of the Linux kernel, specifically within the logic responsible for copying audio infoframe data into a connector-specific structure. The root cause is a mismatch between the source and destination buffer sizing during the invocation of a helper memory copy function.\nThe implementation incorrectly utilizes the size of the destination buffer—a generic structure designed to accommodate diverse data blocks—rather than the actual size of the source structure, which is a specific and smaller data block. During execution, the kernel attempts to copy 60 bytes of data originating from a 28-byte heap-allocated block. Because the copy operation does not respect the boundary of the source allocation, it reads 32 bytes of adjacent, out-of-bounds kernel memory.\nThe attack flow involves an adversary or system process triggering an HDMI connector event that requires the population of the audio infoframe. When the helper function is called, it blindly proceeds with the larger length parameter. In a scenario where the source buffer sits at the end of a memory page, this read operation can trigger a page fault or a kernel access violation (accvio), resulting in a system crash or denial of service.\nFrom an exploitation perspective, the vulnerability acts as a primitive for kernel memory disclosure. By reading adjacent data, an attacker may potentially leak sensitive information stored in the heap, such as kernel pointers, structures, or other sensitive objects. Although the vulnerability does not involve a write operation—thereby limiting its utility for direct memory corruption—the information leakage could be leveraged as part of a multi-stage exploit chain to bypass KASLR (Kernel Address Space Layout Randomization) or other hardening mechanisms.\nThe technical fix involves replacing the erroneous destination-based size parameter with the source-based size. Furthermore, the implementation introduces a build-time check (e.g., using BUILD_BUG_ON) to ensure the source size is strictly validated against the expected destination buffer capacity, thereby preventing future regressions where structural changes might inadvertently bypass standard runtime checks. No authentication or elevated privileges are strictly required to reach the vulnerable code path if the HDMI interface is accessible to the user or controlled via standard DRM ioctls."
}