-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2022-42336 / XSA-431 Mishandling of guest SSBD selection on AMD hardware ISSUE DESCRIPTION ================= The current logic to set SSBD on AMD Family 17h and Hygon Family 18h processors requires that the setting of SSBD is coordinated at a core level, as the setting is shared between threads. Logic was introduced to keep track of how many threads require SSBD active in order to coordinate it, such logic relies on using a per-core counter of threads that have SSBD active. When running on the mentioned hardware, it's possible for a guest to under or overflow the thread counter, because each write to VIRT_SPEC_CTRL.SSBD by the guest gets propagated to the helper that does the per-core active accounting. Underflowing the counter causes the value to get saturated, and thus attempts for guests running on the same core to set SSBD won't have effect because the hypervisor assumes it's already active. IMPACT ====== An attacker with control over a guest can mislead other guests into observing SSBD active when it is not. VULNERABLE SYSTEMS ================== Only Xen version 4.17 is vulnerable. Only x86 AMD systems are vulnerable. The vulnerability can be leveraged by and affects only HVM guests. MITIGATION ========== Running PV guests only will prevent the vulnerability. Setting `spec-ctrl=ssbd` on the hypervisor command line will force SSBD to be unconditionally active. NOTE REGARDING LACK OF EMBARGO ============================== This issue was discussed in public already. RESOLUTION ========== Applying the attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa431.patch xen-unstable - Xen 4.17.x $ sha256sum xsa431* e71a8b7e251adf4832a4de9e452c2fd895a56314729c54698d10e344f1996a99 xsa431.patch $ -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmRjkhsMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZDb8H/0vKLOgBhwKCVc8VYm59FIALd69k4qCLcwwfDuro jFum5ATC3Cbx+iEXD2URFY6O+eE71mMBqw3/GT/BiKvsBHQhX5lsJUpxZFscqW9J diM69a9BYuNNy+qW3TsslRsW9WGHH5bZoAhxpNKgciE17svJ76IRUsgNf806VRX+ VBI61wK2s9oqzfTazhQVR9zxFLANTyw7M4EtUXs0y49IUFjnSeVpW7/PdoloPC1C m0SG6HSIJ4bH+yAWMqY5GYYVgJOkaStxEM6YLGjT/V078xcDyW2cie3BOtQ8/BI0 FJ7iwEh932k7VLtd+htBF3vo7CD+teGneeaktqKK2h55ps0= =dmhW -----END PGP SIGNATURE-----