CVE-2024-26603

What it actually does

The kernel's signal handling path trusts a user-supplied xstate_size value from the signal frame instead of the authoritative fpstate user_size, allowing a crafted sigreturn frame to cause XRSTOR to repeatedly fault on unmapped memory while fault_in_readable succeeds, resulting in an unkillable infinite loop.

Why it matters to the business

Local users can trigger a persistent denial of service that freezes affected processes or threads, reducing system availability and requiring a reboot to recover; the issue affects any kernel-based deployment that has not applied the fix.

How an attack unfolds

An attacker with local access crafts a malicious signal frame containing an xstate_size smaller than the actual xfeatures require and arranges for part of the associated buffer to be unmapped, then invokes sigreturn; the kernel enters the fault-retry loop and never exits.

How to fix it

Upgrade the kernel to a version containing commit 68eaa804c9bafdc5f798e114e9ba00161425dd71 (or later equivalent) so that fault_in_readable always uses fpstate->user_size; apply the same change to any distribution kernels or rebuilds in use.

How to confirm the fix worked

Confirm the running kernel contains the referenced commit or a back-port that replaces fx_sw->xstate_size with fpstate->user_size in the fault-in logic; test by attempting to deliver a deliberately undersized signal frame and verifying the process terminates rather than spinning.

Typical attack path

1. Obtain local execution on a vulnerable system
2. Map a signal frame whose fx_sw.xstate_size under-reports required state
3. Unmap trailing portions of the FPU buffer so XRSTOR will fault
4. Invoke rt_sigreturn or equivalent to trigger the kernel path
5. Observe the resulting unkillable loop in the target process

How to detect it

Look in kernel logs for repeated XRSTOR fault messages or processes stuck in kernel state 'fpu'; inspect audit or syscall logs for unusual rt_sigreturn sequences from untrusted users; no network indicators exist.

What your security team should do

• Prioritize patching all exposed Linux systems within the normal change window
• Restrict local unprivileged accounts where feasible until patches are deployed
• Add kernel version checks to vulnerability scanners and asset inventories
• Monitor for any public exploit code that appears after publication