CVE-2026-31482

What it actually does

This Linux kernel flaw affects the s390/s390x architecture entry path. A prior kernel change removed code that loaded register r12 during kernel entry but did not add r12 to the register-clearing sequence. As a result, r12 may retain an unexpected or stale value across certain transitions from user space into the kernel. The assessed impact is local denial of service: a local authenticated user may be able to trigger unstable kernel behavior, crashes, or system unavailability. There is no indicated confidentiality or integrity impact, and exploitation requires local code execution privileges on an affected s390/s390x Linux system.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems running on IBM Z / s390x-class platforms, causing service interruption, workload restarts, failover events, or unplanned maintenance. Because exploitation requires local access and EPSS is very low with no known KEV listing or mature public exploit, internet-scale exploitation is unlikely; however, multi-user systems, shared compute platforms, and environments where untrusted users can run local code should treat this as a higher operational risk.

How an attack unfolds

An attacker first needs the ability to execute code locally on an affected s390/s390x Linux host, such as through a shell account, compromised application user, container escape prerequisite, batch job, or other local execution path. The attacker then repeatedly invokes kernel entry paths, such as system calls, interrupts, exceptions, or signal-related transitions, while controlling or influencing general-purpose register state from user space. Because r12 was not consistently scrubbed on entry, the kernel may encounter an unexpected register value in code paths that assume a sanitized register state. If the vulnerable path is reached, the result may be a kernel oops, panic, or other stability failure, producing a denial-of-service condition. There is no evidence from the provided data of remote exploitation, privilege escalation, data theft, ransomware use, or active exploitation by named threat actors.

How to fix it

Upgrade affected Linux kernel packages to a vendor-supported release that includes the upstream fix for the s390 entry code change: adding r12 to the kernel-entry register scrub sequence. Because no exact fixed package versions were provided, use the relevant Linux distribution security advisory for the deployed kernel stream and confirm the patch for `s390/entry: Scrub r12 register on kernel entry` is included. Reboot systems after installing the fixed kernel so the patched kernel is active. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads on s390/s390x hosts, enforcing strong container isolation, applying least privilege to batch and application users, and using high-availability controls to reduce the operational impact of a kernel crash.

How to confirm the fix worked

Confirm whether systems are affected by identifying Linux hosts running on s390/s390x architecture and comparing their active kernel version against the vendor advisory or patched kernel build. Validate remediation by confirming the running kernel, not only the installed kernel package, is the fixed version after reboot. Where source or symbol verification is available, confirm the s390 entry code includes the added `xgr %r12,%r12` register scrub instruction. Review distribution changelogs or package metadata for the fix text `s390/entry: Scrub r12 register on kernel entry`. Also verify that crash logs stop showing unexplained kernel oops or panic events associated with local process activity after the patched kernel is deployed.

Typical attack path

1. Gain local code execution on an affected Linux s390/s390x system.
2. Run a program or script that repeatedly transitions from user mode into kernel mode while manipulating register state.
3. Trigger a vulnerable kernel entry path where r12 is not scrubbed as expected.
4. Cause kernel instability, an oops, panic, or system crash.
5. Leverage the crash to disrupt workloads, force reboots, or degrade service availability.

How to detect it

Look for evidence of attempted or successful local denial-of-service activity on affected s390/s390x Linux systems. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, crash dump repositories such as kdump/vmcore storage, audit logs for local process execution, EDR telemetry, batch scheduler logs, and authentication logs showing users active shortly before a crash. Focus on unexplained kernel oops or panic events, repeated abnormal reboots, watchdog-triggered resets, or bursts of local programs making rapid system calls immediately before instability. Correlate crash timestamps with local user sessions, recently started binaries, cron jobs, containers, or batch workloads. There are no public exploit-specific indicators in the provided data, so detection should emphasize behavioral correlation: local execution followed by kernel instability on s390/s390x systems running an unpatched kernel.

• s390/entry: Scrub r12 register on kernel entry
• xgr %r12,%r12
• Kernel panic - not syncing
• Oops:
• kernel BUG at
• Unable to handle kernel pointer dereference
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• kdump: saving vmcore
• systemd-shutdown: Rebooting

What your security team should do

• Inventory Linux systems running on s390/s390x architecture and prioritize those that allow interactive users, batch jobs, shared workloads, or untrusted local code execution.
• Apply the vendor-fixed Linux kernel and reboot to activate it; track remediation by running kernel version rather than installed package version alone.
• Restrict local execution rights on affected systems until patched, especially for non-administrative users and shared workload accounts.
• Review recent kernel crash, oops, panic, and unexpected reboot events on s390/s390x hosts for signs of possible abuse or reliability impact.
• Ensure monitoring alerts on kernel panics, oops events, watchdog resets, and abnormal reboot patterns are enabled for business-critical s390/s390x workloads.
• Because this issue is not listed in KEV, has no known ransomware association, and has very low EPSS, prioritize it behind actively exploited remote-code-execution issues unless the affected systems host untrusted local users or critical workloads.