CVE-2023-52598

What it actually does

Race condition in s390 ptrace FPC register handling allows temporary FPC value loaded for validity test to be saved as the tracer's user-space state on interrupt if FP/VX registers are used in interrupt context, causing the tracer to retain the traced process's FPC value on return to user space.

Why it matters to the business

Debugging or tracing tools on s390 Linux systems can experience silent floating-point state corruption, leading to incorrect application behavior, crashes, or potential privilege escalation when tracing untrusted processes; low exploitability but affects kernel stability in development and security tooling environments.

How an attack unfolds

An attacker with permission to attach via ptrace to a target process on s390 modifies the FPC register through the ptrace interface; an interrupt occurring during the temporary load in test_fp_ctl() that uses FP/VX registers causes save_fpu_regs() to capture the wrong value, which is then incorrectly restored to the tracer process.

How to fix it

Upgrade the Linux kernel to a version containing commit 6ccf904aac0292e1f6b1a1be6c407c414f7cf713 which saves FPU registers with save_fpu_regs() before calling test_fp_ctl().

How to confirm the fix worked

Verify the running kernel includes commit 6ccf904aac0292e1f6b1a1be6c407c414f7cf713; exercise ptrace FPC modification under interrupt load and confirm the tracer's FPC register is preserved correctly.

Typical attack path

1. Obtain ptrace attachment capability to a target process
2. Use PTRACE_SETREGS or equivalent to alter the FPC register value
3. Trigger or wait for an interrupt context that performs FP/VX operations
4. Allow test_fp_ctl() to complete without proper FPU save, resulting in FPC corruption on return to user space in the tracer

How to detect it

Review system logs for unexpected floating-point register state changes during ptrace sessions; correlate with process tracing events and interrupt activity on s390; no public exploitation artifacts reported.

What your security team should do

• Apply the kernel patch containing commit 6ccf904aac0292e1f6b1a1be6c407c414f7cf713 on all s390 systems
• Restrict ptrace usage via Yama LSM or CAP_SYS_PTRACE minimization where possible
• Monitor for kernel updates in stable branches and test tracing workloads post-upgrade