CVE-2026-31483

What it actually does

This vulnerability affects the Linux kernel on s390 architecture. The syscall number supplied by a local userspace process is used during syscall dispatch without an appropriate speculative-execution bounds barrier such as array_index_nospec(). Although normal architectural bounds checks may prevent intended out-of-range table access, speculative execution can transiently access entries beyond the syscall function pointer table. The assessed impact is primarily local availability risk, with a privileged or unprivileged local user potentially triggering kernel instability, crashes, or denial of service depending on kernel configuration and hardware behavior.

Why it matters to the business

Organizations running Linux on IBM s390 or s390x systems may face local denial-of-service risk if an attacker obtains a local account or code execution on the system. Successful exploitation could disrupt workloads, require system reboot, and affect availability of business-critical mainframe or Linux-on-Z environments. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is lower than remotely exploitable or actively exploited kernel flaws, but it should still be remediated during normal kernel maintenance cycles, especially on multi-user or shared hosting systems.

How an attack unfolds

An attacker must first be able to execute code locally on an affected s390 Linux system. They then run a program that repeatedly invokes syscalls with attacker-controlled syscall numbers intended to stress the syscall dispatch path. Because the syscall number is directly influenced by userspace and the dispatch path lacks a speculative bounds barrier, the CPU may transiently access outside the intended syscall table during misprediction. In practical terms, exploitation would likely be attempted as a local stability or denial-of-service attack rather than a remote compromise. There is no indication from the provided intelligence that this vulnerability is being used in ransomware campaigns, exploited by named threat actors, or associated with mature public exploit code.

How to fix it

Upgrade affected Linux kernels on s390/s390x systems to a vendor-supported release that includes the fix adding a speculative-execution boundary for syscall dispatch. No exact fixed package versions were provided, so use distribution vendor advisories for Red Hat, SUSE, Ubuntu, Debian, IBM LinuxONE/Linux on Z, or other supported kernel channels to identify the corrected kernel build. Apply the kernel update, regenerate bootloader/initramfs artifacts if required by the distribution, and reboot into the fixed kernel. Where immediate patching is not possible, reduce exposure by limiting local shell access, enforcing least privilege, isolating untrusted workloads, restricting interactive access to shared s390 systems, and monitoring for abnormal local syscall-stress or kernel-crash activity. Mitigations are not a substitute for the kernel fix.

How to confirm the fix worked

Confirm exposure by checking whether systems are Linux on s390 or s390x architecture and whether the running kernel predates the vendor advisory containing the syscall dispatch nospec fix. Use commands such as uname -m, uname -r, and distribution package tools to compare the installed and running kernel against vendor-fixed versions. After remediation, verify the system has rebooted into the updated kernel, not merely installed it. Review vendor changelogs or kernel source patches for references to s390 syscall dispatch table bounds protection, array_index_nospec(), or the corresponding CVE. Validate that no affected older kernel remains configured as the default boot entry on production systems.

Typical attack path

1. Gain local code execution on an affected Linux s390 or s390x system through a user account, compromised application, container escape prerequisite, or other local execution path.
2. Run a local program that issues crafted syscall numbers to exercise the vulnerable syscall dispatch path.
3. Trigger speculative out-of-bounds access past the syscall function pointer table due to the missing nospec boundary.
4. Cause kernel instability, a crash, panic, or other denial-of-service condition if the platform and kernel behavior permit practical exploitation.
5. Disrupt hosted workloads until the system recovers, is rebooted, or is patched.

How to detect it

There are no reliable network indicators for this vulnerability because exploitation requires local code execution and occurs inside the kernel syscall dispatch path. Historical exploitation detection should focus on host telemetry from affected s390/s390x systems. Review kernel logs, journal logs, crash dumps, kdump/vmcore artifacts, audit logs, and EDR process telemetry for unexplained kernel oops, panic, soft lockup, hard lockup, general protection, or repeated abnormal syscall-heavy local programs around the time of outages. Look for short-lived binaries or scripts executed by local users immediately before system instability. Because speculative-execution behavior generally does not leave deterministic forensic artifacts, absence of logs does not prove non-exploitation. Correlate crashes with user login records, sudo activity, container workload starts, new executable creation in temporary directories, and abnormal CPU spikes. No named threat actors or ransomware campaigns are currently associated with this vulnerability in the provided intelligence.

• kernel panic
• Kernel panic - not syncing
• Oops:
• BUG: unable to handle kernel
• soft lockup
• hard lockup
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP
• general protection fault
• segfault
• /var/crash/
• /var/lib/systemd/coredump/
• /proc/vmcore
• kdump
• s390
• s390x

What your security team should do

• Prioritize inventory of Linux systems running on s390 or s390x architecture; non-s390 architectures are not the primary affected target described here.
• Patch affected systems through the appropriate Linux distribution kernel update channel and reboot into the fixed kernel.
• Prioritize shared, multi-user, internet-facing workload hosts, CI/build systems, and systems where untrusted users or tenants can execute local code.
• If patching must be delayed, restrict local login access, remove unnecessary accounts, harden sudo and privilege boundaries, and isolate untrusted workloads.
• Monitor kernel logs for crashes, oops events, panics, or unusual syscall-stress behavior on s390 systems until remediation is complete.
• Track vendor advisories because exact fixed versions were not provided in the input and may differ by distribution kernel stream.
• Do not treat the low EPSS and absence from KEV as a reason to ignore the issue; treat it as routine-priority kernel maintenance unless local untrusted execution is common in the environment.