Database/Firmware, BMC & network fabric
AMD processors - power side channel on cache line data changes: An authenticated attacker who can read CPU power
Impact
An authenticated attacker who can read CPU power consumption can infer data as it moves through a shared cache line, because the energy cost of a write depends on how many bits flip. Collide+Power generalised this into a technique that works against any victim sharing the cache hierarchy, without needing the victim to have any specific code pattern. Leakage rates are low - this is not a fast exfiltration channel - but it is a channel that exists between tenants on the same socket regardless of what your isolation configuration says.
Who can reach it
Local, authenticated, needs access to power/energy telemetry (RAPL-style interfaces) and cache co-residency with the victim. Reachable from a container if you expose power telemetry into it, which some GPU and CPU monitoring stacks do.
What to do
Mitigated primarily by restricting who can read fine-grained power telemetry: on Linux, the RAPL/energy interfaces should be root-only (this was tightened upstream), and you should not be passing power monitoring into tenant containers. Check what your DCGM-equivalent AMD telemetry stack exposes and to whom - operators often mount host telemetry paths into monitoring sidecars that tenants can reach. Kernel/driver-level fix plus a config review; no firmware flash and no reboot if you are only tightening permissions. The zero-cost mitigation available today is scheduling policy rather than patching: these attacks need the attacker and victim co-resident on sibling SMT threads, so either disable SMT (costing roughly 10-25% throughput on most inference and training workloads) or enforce core isolation so no two tenants ever share a physical core. On a GPU fleet the CPU is rarely the bottleneck, which makes disabling SMT a cheaper trade than it looks on paper.
References
Related entries
- Linux kernel (drivers/vfio/pci/mlx5): Pages allocated for a device migration buffer are not freed when adding them toCVE-2024-56742 · Linux kernel (drivers/vfio/pci/mlx5)Medium
- Intel / Solidigm SSD, SSD DC and Optane SSD firmwareCVE-2021-33082 · Intel / Solidigm SSD, SSD DC and Optane SSD firmware - NVMe Sanitize (Block Erase) leaves prior data recoverableMedium
- AMD SEV firmware - use-after-free allowing a SINGLE_SOCKET guest to activate on the wrong socket (AMD-SB-3023): ACVE-2025-0031 · AMD SEV firmware - use-after-free allowing a SINGLE_SOCKET guest to activate on the wrong socket (AMD-SB-3023)Medium
- AMD CPU pipeline configuration - SEV-SNP guest stack pointer corruption: A write-what-where condition in CPU pipelineCVE-2025-29943 · AMD CPU pipeline configuration - SEV-SNP guest stack pointer corruptionMedium
- AMD SEV firmware - ASID range enforcement between SEV-ES and SEV-SNP guests: A malicious hypervisor can launch a SEV-ESCVE-2025-48517 · AMD SEV firmware - ASID range enforcement between SEV-ES and SEV-SNP guestsMedium
- Broadcom NetXtreme-E network adapter firmware: The lower-severity half of the same Positive Technologies NetXtreme-ECVE-2025-56548 · Broadcom NetXtreme-E network adapter firmwareMedium
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.