CVE-2026-31561

In the Linux kernel, the following vulnerability has been resolved:

x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask

Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so

that whenever something else modifies CR4, that bit remains set. Which

in itself is a perfectly fine idea.

However, there's an issue when during boot FRED is initialized: first on

the BSP and later on the APs. Thus, there's a window in time when

exceptions cannot be handled.

This becomes particularly nasty when running as SEV-{ES,SNP} or TDX

guests which, when they manage to trigger exceptions during that short

window described above, triple fault due to FRED MSRs not being set up

yet.

See Link tag below for a much more detailed explanation of the

situation.

So, as a result, the commit in that Link URL tried to address this

shortcoming by temporarily disabling CR4 pinning when an AP is not

online yet.

However, that is a problem in itself because in this case, an attack on

the kernel needs to only modify the online bit - a single bit in RW

memory - and then disable CR4 pinning and then disable SM*P, leading to

more and worse things to happen to the system.

So, instead, remove the FRED bit from the CR4 pinning mask, thus

obviating the need to temporarily disable CR4 pinning.

If someone manages to disable FRED when poking at CR4, then

idt_invalidate() would make sure the system would crash'n'burn on the

first exception triggered, which is a much better outcome security-wise.