GPU VulnDB

Database/Firmware, BMC & network fabric

AMD Zen 2 op cache: shared resources are not properly isolated, corrupting instructions

CVSS 8.8CVE-2026-46174Firmware, BMC & network fabriccurated

Impact

The op cache on Zen 2 cores can share entries across contexts that should be isolated, which the kernel commit describes as causing instruction corruption. On a GPU node this is a cross-context integrity problem on the host CPU rather than on the accelerator: Zen 2 EPYC (Rome) hosts are common as GPU head nodes, and anything that corrupts executed instructions can affect a co-resident tenant, a container, or a guest VM sharing a core. The upstream record gives no exploit detail and no proof-of-concept, so treat the realistic risk as corruption and unreliability of SMT-shared execution, not a demonstrated data-theft path. NVD scores it 8.8 local with changed scope, which is the kernel CNA's standard rating and should not be read as a validated cross-tenant exploit.

Who can reach it

Local code execution on an affected Zen 2 host - any tenant that can run instructions on a core, including inside an unprivileged container or a guest VM. No special privilege is named in the record.

What to do

Take the stable kernel containing the x86/CPU/AMD fix (five stable branches carry it; see the git.kernel.org links) and reboot each affected Zen 2 host - the mitigation is applied at CPU init, so a live-patch of the running kernel is not sufficient. Pair it with the vendor's current AMD microcode and BIOS for the platform as a matter of course. The upstream commit message does not state a specific fixed release tag, so pick the backport that matches the branch you run; no vendor advisory with an affected-SKU list is present in this record.

References

Related entries

All Firmware, BMC & network fabric entries

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.