CVE-2026-89460

What it actually does

On s390 Linux, a race between CPU hotplug and per-task CPUMF (cpu-measurement facility) event setup leaves per-CPU counter state unallocated for CPUs that were offline when the first task-context event was created. When the scheduler later migrates an instrumented task onto a newly onlined CPU, cpumf_pmu_add() calls this_cpu_cfhw(), receives NULL, and the kernel oopses with a NULL pointer dereference. The crash is confined to the s390 cpum_cf PMU path and requires task-context perf events or /dev/hwctr sessions coinciding with a CPU online transition; system-wide (cpu == -1) tracking was incomplete for hotplug. The patch introduces prepare/dead hotplug callbacks and a tskcnt user count so per-CPU structures exist before the CPU runs tasks, and NULLs references before free to avoid stale interrupt-handler use.

Why it matters to the business

This is an availability defect: a kernel panic takes down the entire s390 LPAR or guest and all workloads on it. Only IBM Z / s390 systems that use CPUMF with per-task perf or hardware-counter sessions during CPU hotplug are in scope; other architectures are unaffected. Likelihood of weaponized use is very low (EPSS about 0.0017 and flat over 30 days, not in CISA KEV, no known ransomware or named-actor use, exploit maturity none). Residual operational risk is accidental or local denial of service in mainframe environments that dynamically add CPUs while profiling. The issue has been public for about 31 days; treat as a reliability/availability patch, not an emergency internet-facing incident.

How an attack unfolds

A local actor on an s390 host needs conditions where a per-task hardware-counter session is created while some CPUs are offline, then those CPUs are brought online while the session is still live. Event setup allocates cpu_cf_events only for CPUs that were online at init, so a later CPU has no per-CPU CPUMF state. The kernel scheduler may then place the instrumented process on that CPU; the PMU add callback assumes the per-CPU pointer is valid, dereferences NULL, and panics. Privileges typically required to online/offline CPUs and to open hardware counters make this more a local or operator-triggered crash than a remote or unprivileged break-in. There are no public exploits, no KEV listing, and no attributed campaigns.

How to fix it

Apply Linux kernel updates that include the s390/cpum_cf fix introducing CPU hotplug prepare/dead callbacks, tskcnt tracking for task-context and /dev/hwctr users under pmc_reserve_mutex, and NULLing of per-CPU references before free. Use your distribution’s kernel package (or upstream stable) that contains this change; no per-product version list was supplied with this record, so confirm the changelog mentions s390/cpum_cf hotplug prepare/dead handling. Until patched, avoid CPU hotplug while per-task perf events or /dev/hwctr sessions are active, and restrict who can online/offline CPUs and open hardware counters. Rebuild and redeploy custom s390 kernels from a tree that includes the fix.

How to confirm the fix worked

Confirm the running s390 kernel changelog or source contains cpum_cf CPUHP prepare/dead callbacks and cpu_cf_root::tskcnt (not only online-CPU allocation at first event). After patching, verify uname/package version against the vendor advisory, then exercise CPU online/offline while a per-task cycles (or equivalent CPUMF) session is running and confirm no oops. Review dmesg/journal for prior cpumf_pmu_add NULL dereferences. Inventory s390 guests/LPARs still on unfixed kernels and any automation that hotplugs CPUs during profiling.

Typical attack path

1. Obtain local access on an s390 Linux system where CPUMF and per-task perf or /dev/hwctr sessions can run.
2. Cause or wait for one or more CPUs to be offline when a task-context counter event is created, so those CPUs never receive cpu_cf_events allocation.
3. Bring those CPUs online (or wait for an administrator or orchestrator to do so) while the event remains active.
4. Wait for the scheduler to migrate the instrumented task onto a newly onlined CPU.
5. The PMU add path runs against a NULL per-CPU pointer and panics the kernel, denying service to every workload on that host.

How to detect it

This leaves a kernel oops, not a stealth implant. Search kdump/vmcore, dmesg, journalctl -k, and serial/HMC console logs on s390 hosts for a NULL pointer dereference in cpumf_pmu_add with last breaking address in this_cpu_cfhw, on a call chain through event_sched_in, perf_event_context_sched_in, and finish_task_switch. Correlate the oops timestamp with CPU online/hotplug messages and concurrent perf or /dev/hwctr use. Absence of that oops does not prove the host was never vulnerable—only that this crash path was not taken. There are no network IOCs or malware artifacts.

• cpumf_pmu_add+
• this_cpu_cfhw+
• Unable to handle kernel pointer dereference in virtual kernel address space
• perf_event_context_sched_in
• __perf_event_task_sched_in
• event_sched_in+
• pmu_groups_sched_in

What your security team should do

• Patch s390 Linux kernels first; other architectures are not affected by this CPUMF path.
• Until patched, freeze CPU hotplug during per-task perf or /dev/hwctr use and limit CAP_SYS_ADMIN / sysfs CPU online control and hardware-counter access.
• Hunt historical kernel oops/crash dumps for cpumf_pmu_add / this_cpu_cfhw NULL dereferences correlated with CPU online events.
• Track distro kernel advisories for the s390/cpum_cf hotplug fix; EPSS is low and the CVE is not KEV, so schedule as a standard availability patch unless you hotplug CPUs in production during profiling.
• Do not treat this as ransomware or remote RCE; prioritize as local DoS / reliability on IBM Z only.