AMD Video Decoder Engine Firmware (VCN FW) - debug code left active: Debug code was shipped active in AMD's Video Core

Impact

Debug code was shipped active in AMD's Video Core Next firmware, so a maliciously crafted command makes the VCN firmware read and write hardware registers. This is the shipped-debug-hooks failure applied to a GPU IP block: an attacker who can submit VCN commands - which any workload with the GPU device node can - gets arbitrary hardware register access, and hardware registers are how you reconfigure memory apertures, power state and access control on the device. On MI-series parts the VCN block is present whether or not your AI workload uses video decode, so 'we do not do video' is not a mitigation.

Who can reach it

Local, by submitting a crafted command to the video decode engine - reachable from any process holding /dev/dri/renderD*, i.e. an unprivileged tenant container.

What to do

Fixed in AMD GPU firmware, which on Instinct parts is delivered as a firmware bundle through the ROCm/amdgpu driver package (the PSP loads the signed blobs at driver init) rather than through the server BIOS. Practically: update the AMD GPU driver/firmware package, then **drain the node and reboot** - the firmware is loaded once at driver init, so a reload of the module with no process holding /dev/kfd is the minimum, and a reboot is what you will actually schedule. Some fixes at this layer also require a **GPU VBIOS flash** via AMD's amdvbflash/amdfwtool, which is an offline, per-card operation with real bricking risk - check the AMD bulletin for whether a VBIOS update is called out before assuming a driver package covers it. If your workloads genuinely never touch video decode, consider whether the VCN block can be gated off in your deployment as a stopgap - but verify rather than assume, since the ROCm stack initialises IP blocks it does not use.

References