ASPEED video engine capture driver (drivers/media/platform/aspeed) - iKVM path: The video engine writes past

CVSS 7.8CVE-2023-52916Firmware, BMC & network fabriccurated

Impact

The video engine writes past its capture buffer when the host is driving a 1600x900 mode, corrupting whatever BMC kernel memory sits after it. The reported repro is mundane: run iKVM with virtual media mounted while the BMC is under memory pressure. Since the resolution is chosen by the host, a tenant with control of the server's display output can steer the BMC into the corrupting mode on demand. Realistically this is a BMC crash - which on a GPU node means losing remote power control and console right when you need it - but out-of-bounds writes driven by attacker-chosen geometry are the raw material for something worse.

Who can reach it

The host side picks the video mode, so any tenant with root on the bare-metal node can select it. Triggering the corruption additionally needs the BMC's iKVM/video capture to be running, which is the normal state on fleets that leave remote console available.

What to do

Kernel fix backported into stable; reaching your fleet means a BMC firmware flash per node, out-of-band, waiting on the ODM rebase. Config-only stopgap: disable the iKVM/video capture service on nodes that do not need graphical remote console. On a GPU fleet that is usually acceptable - operators run serial-over-LAN and Redfish, not KVM - and it removes both this bug and the video-engine DMA issue below without touching firmware.

References

https://nvd.nist.gov/vuln/detail/CVE-2023-52916 https://git.kernel.org/stable/c/4c823e4027dd1d6e88c31028dec13dd19bc7b02d https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.