Database/Firmware, BMC & network fabric
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
Related entries
- EDK II NetworkPkg (IScsiDxe, iSCSI login response processing): A hostile iSCSI target answers the firmware initiatorCVE-2024-38805 · EDK II NetworkPkg (IScsiDxe, iSCSI login response processing)Medium
- Lenovo XClarity Administrator (LXCA, insufficient authorization): An authenticated LXCA user without sufficientCVE-2024-45104 · Lenovo XClarity Administrator (LXCA, insufficient authorization)Medium
- Keylime verifier: hardcoded TPM quote nonce lets a compromised node replay stockpiled attestationsCVE-2026-6420 · Keylime verifier (TPM quote nonce, push attestation model)Medium
- Arista EOS: ingress ACLs on shared SVIs stop enforcing after a secondary switch card eventCVE-2026-73451 · Arista EOS ingress security ACLs on shared-mode SVIs (dual switch card systems)Medium
- Linux KVM - PV TLB shootdown leaks memory between guest processes: In a KVM guest with paravirtualised TLB enabled, oneCVE-2019-3016 · Linux KVM - PV TLB shootdown leaks memory between guest processesMedium
- APC Network Management Card 2 (AP9630/AP9631/AP9635) in Smart-UPS, Symmetra and Galaxy 3500: Stored/reflectedCVE-2021-22810 · APC Network Management Card 2 (AP9630/AP9631/AP9635) in Smart-UPS, Symmetra and Galaxy 3500Medium
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.