ASPEED video engine driver clock/reset sequencing (drivers/media/platform/aspeed): The driver brings the video engine

Impact

The driver brings the video engine out of reset in the wrong order relative to its two clocks, and the hardware responds by issuing DMA writes to effectively random BMC memory. This is a DMA engine scribbling on the management processor's RAM with no software mediating the target address - the failure mode is silent BMC state corruption and unexplained BMC hangs or reboots. Operators usually log these as flaky hardware and RMA the board; the actual cost is a management processor whose memory integrity you cannot reason about, on every node running an affected image with video capture enabled.

Who can reach it

Triggers on video engine initialization, i.e. whenever iKVM/video capture is started or restarted on an affected BMC image. No attacker required for the corruption itself, but a host-side tenant who can force display-mode changes can force the reinit repeatedly.

What to do

Fixed in the kernel driver and backported to stable branches; delivery is a BMC firmware flash, per node, out-of-band, ODM-gated. Config-only mitigation is to leave the video capture service stopped on nodes that do not use graphical console. Worth pairing with a check of your BMC crash/reboot telemetry - if you have unexplained BMC resets on ASPEED nodes with iKVM enabled, this is a candidate cause rather than bad silicon.

References