Borislav Petkov

The issue concerns the Linux kernel, specifically with x86/CPU/AMD, where certain Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE instructions. However, using these instructions can cause a random host reboot. These instructions are not intended to be advertised on Zen4 client systems.

The issue is related to a bug in the x86/kexec component of the Linux kernel, where the call to `cc platform has()` triggers a fault and system crash if call depth tracking is active. This occurs because the GS segment has been reset by `load segments()` and `GS BASE` is now 0, but call depth tracking uses per-CPU variables to operate. The fix involves calling `cc platform has()` earlier in the function when GS is still valid.

The vulnerability is related to the `sys membarrier` function in the Linux kernel's `membarrier` component. It can cause a denial of service due to uncontrolled resource consumption. On some systems, `sys membarrier` can be very expensive, leading to overall slowdowns. To prevent this, a lock has been put on the path to serialize accesses and prevent the function from being called at too high a frequency.

A rare kernel panic scenario can occur due to an erratum on fast string copy instructions in the Linux kernel. This issue happens when an uncorrected error is present in the first cache line of a page, and the kernel executes page copy from the page immediately before that page. The fast string copy instructions could consume an uncorrectable memory error and raise a Machine Check Exception (MCE). This erratum is confirmed by Intel to only apply to Skylake, Cascade Lake, and Cooper Lake generations.

The issue is related to the `restore fpu checking` function in the Linux kernel, which does not properly clear pending exceptions before executing an EMMS instruction on AMD K7 and K8 platforms. This can be exploited by local users to cause a denial of service or potentially gain privileges through a crafted application.