CVE-2026-31561

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu: Remove X86_CR4_FRED from the CR4 pinned bits mask<br /> <br /> Commit in Fixes added the FRED CR4 bit to the CR4 pinned bits mask so<br /> that whenever something else modifies CR4, that bit remains set. Which<br /> in itself is a perfectly fine idea.<br /> <br /> However, there&amp;#39;s an issue when during boot FRED is initialized: first on<br /> the BSP and later on the APs. Thus, there&amp;#39;s a window in time when<br /> exceptions cannot be handled.<br /> <br /> This becomes particularly nasty when running as SEV-{ES,SNP} or TDX<br /> guests which, when they manage to trigger exceptions during that short<br /> window described above, triple fault due to FRED MSRs not being set up<br /> yet.<br /> <br /> See Link tag below for a much more detailed explanation of the<br /> situation.<br /> <br /> So, as a result, the commit in that Link URL tried to address this<br /> shortcoming by temporarily disabling CR4 pinning when an AP is not<br /> online yet.<br /> <br /> However, that is a problem in itself because in this case, an attack on<br /> the kernel needs to only modify the online bit - a single bit in RW<br /> memory - and then disable CR4 pinning and then disable SM*P, leading to<br /> more and worse things to happen to the system.<br /> <br /> So, instead, remove the FRED bit from the CR4 pinning mask, thus<br /> obviating the need to temporarily disable CR4 pinning.<br /> <br /> If someone manages to disable FRED when poking at CR4, then<br /> idt_invalidate() would make sure the system would crash&amp;#39;n&amp;#39;burn on the<br /> first exception triggered, which is a much better outcome security-wise.