On Fri, Jun 26, 2026 at 05:00:37AM +0000, sashiko-bot@kernel.org wrote:

[Severity: Critical]
This is a pre-existing issue, but Memory Protection Keys (PKU) isolation
can be bypassed because we don't verify X86_FEATURE_PKU against the
presence of XFEATURE_PKRU in xstate here.

If a hypervisor reports X86_FEATURE_PKU in CPUID but masks out the
XFEATURE_PKRU xstate component, the kernel's setup_pku() enables CR4.PKE
and forces X86_FEATURE_OSPKE.  Because X86_FEATURE_OSPKE is artificially
forced, the feature is not cleared.

CR4.PKE=1 permits userspace to use WRPKRU, but because XCR0.PKRU=0,
xsaves/xrstors silently ignore the PKRU register during task context
switches, leading to state leakage across tasks.

Should we also validate PKU against missing xstate components in this
function to prevent isolation bypass?

I *think* Sashiko means here our preexisting fpu__init_system_xstate() here
but I'm not sure...

[Severity: High]
Does this logic get bypassed if XSAVE or FPU support is missing?

Earlier in fpu__init_system_xstate(), there are early returns if
X86_FEATURE_FPU or X86_FEATURE_XSAVE are missing:

	if (!boot_cpu_has(X86_FEATURE_XSAVE)) {
		pr_info("x86/fpu: x87 FPU will use %s\n",
			boot_cpu_has(X86_FEATURE_FXSR) ? "FXSAVE" : "FSAVE");
		return;
	}

If a hypervisor natively enumerates AVX=1 but XSAVE=0 (such as QEMU
with -cpu host,-xsave), check_cpufeature_deps() only warns about unmet

Yah, we don't care. We won't support non-sensical guest configs.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette