Skip to content

fix: the hdmi receive driver copies edid (extended d... in...#7

Open
orbisai0security wants to merge 1 commit into
Xilinx:masterfrom
orbisai0security:fix-edid-memcpy-bounds-check
Open

fix: the hdmi receive driver copies edid (extended d... in...#7
orbisai0security wants to merge 1 commit into
Xilinx:masterfrom
orbisai0security:fix-edid-memcpy-bounds-check

Conversation

@orbisai0security

Copy link
Copy Markdown

Summary

Fix critical severity security issue in hdmi/xilinx-hdmirx.c.

Vulnerability

Field Value
ID V-001
Severity CRITICAL
Scanner multi_agent_ai
Rule V-001
File hdmi/xilinx-hdmirx.c:369

Description: The HDMI receive driver copies EDID (Extended Display Identification Data) from a connected device into an internal kernel buffer using memcpy. The number of bytes copied is computed as '128 * edid->blocks', where edid->blocks is taken directly from the externally-supplied EDID structure without any validation against the actual allocated size of xhdmi->edid_user. A malicious HDMI device or a crafted ioctl call can set edid->blocks to a large value (e.g., 255), causing the driver to copy up to 32,640 bytes into a buffer that may only hold 512 bytes (4 standard EDID blocks), overflowing the kernel heap and corrupting adjacent memory structures.

Changes

  • hdmi/xilinx-hdmirx.c

Verification

  • Build passes
  • Scanner re-scan confirms fix
  • LLM code review passed

Automated security fix by OrbisAI Security

Automated security fix generated by Orbis Security AI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant