CVE-2026-64369

What it actually does

This is a Linux kernel denial-of-service flaw affecting the s390 architecture in secure execution scenarios. The issue involves DCACHE_WORD_ACCESS behavior where load_unaligned_zeropad() may read eight bytes from an unaligned address and cross a page boundary. If the second page has been donated to the Ultravisor for secure execution, the secure storage access exception path may mishandle the fault and enter an endless exception loop. The practical technical result is that a vulnerable kernel can become stuck in unrecoverable exception handling, causing a hang or severe availability failure rather than memory disclosure or code execution.

Why it matters to the business

Systems running affected Linux kernels on IBM Z / s390 secure execution workloads may experience unexpected hangs or outages if the vulnerable code path is triggered. This can interrupt protected virtual machine workloads, reduce availability of critical services, and require manual recovery or reboot. Public exploitation likelihood appears low at this time given the low EPSS score, lack of known exploited status, and no reported mature exploit, but kernel availability bugs in specialized infrastructure should still be prioritized where s390 secure execution is used.

How an attack unfolds

An attacker, local workload, or otherwise reachable code path would need to cause the kernel on an affected s390 system to perform an unaligned word access through load_unaligned_zeropad() such that the access crosses into a page donated to the Ultravisor for secure execution. When the second-page access raises a secure storage access exception, the kernel's exception handling path may fail to resolve it correctly. Instead of safely recovering from or rejecting the access, the kernel can repeatedly re-enter the exception path, resulting in an endless exception loop and denial of service. There is no indication from the available information that this vulnerability provides privilege escalation, data theft, or remote code execution by itself.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the fix reverting s390 DCACHE_WORD_ACCESS support or otherwise correcting secure storage access exception handling for donated memory. Because no product-specific fixed versions were provided, use vendor advisories for the deployed distribution and kernel stream to identify the exact patched kernel package. Where immediate patching is not possible, reduce exposure by limiting untrusted code execution on affected s390 secure execution hosts, isolating sensitive workloads, scheduling maintenance windows for rapid reboot recovery, and monitoring for kernel hangs or secure storage access exception loops. Treat mitigation as temporary; the reliable remediation is applying a patched kernel.

How to confirm the fix worked

Confirm exposure by checking whether the system is s390 architecture, whether secure execution / Ultravisor-protected workloads are in use, and whether the running kernel includes the vulnerable s390 DCACHE_WORD_ACCESS implementation. Validate remediation by verifying that the installed and booted kernel version matches a vendor-fixed release, not only that the package is installed. Review distribution changelogs for references to reverting s390 DCACHE_WORD_ACCESS, load_unaligned_zeropad(), secure storage access exception handling, or commit b00be77302d7 context. After patching, reboot into the fixed kernel and confirm with uname/package manager output that the active kernel is the updated one.

Typical attack path

1. Identify a target running a vulnerable Linux kernel on the s390 architecture with secure execution / Ultravisor-protected memory in use.
2. Gain the ability to run code or trigger a kernel path that performs relevant unaligned memory access near a page boundary.
3. Cause load_unaligned_zeropad() to read across a boundary where the second page is donated to the Ultravisor.
4. Trigger a secure storage access exception during the cross-page read.
5. Cause the kernel to enter an unresolved exception loop, leading to system hang or service unavailability.

How to detect it

To assess possible prior exploitation or triggering, review kernel logs, hypervisor/console logs, watchdog events, crash records, and availability monitoring for sudden hangs on s390 systems using secure execution. Look for repeated kernel exception messages, secure storage access faults, Ultravisor-related access failures, watchdog lockups, soft lockups, hard lockups, or systems becoming unresponsive without normal shutdown logs. Because the described failure mode is an endless exception loop, there may be limited on-host logging after the fault occurs; external telemetry such as HMC/LPAR console logs, hypervisor events, monitoring gaps, and abrupt reboot records may be more useful than application logs. There are no known public attacker-specific indicators, malware artifacts, or network signatures associated with this issue based on the provided information.

• load_unaligned_zeropad
• do_secure_storage_access
• secure storage access
• Ultravisor
• DCACHE_WORD_ACCESS
• s390/mm
• donated memory
• soft lockup
• hard lockup
• watchdog: BUG: soft lockup
• Kernel panic
• Unable to handle kernel paging request

What your security team should do

• Inventory Linux systems running on s390 / IBM Z and identify those using secure execution or Ultravisor-protected workloads.
• Prioritize kernel updates for affected s390 secure execution hosts, especially systems supporting high-availability or business-critical workloads.
• Consult the operating system vendor's kernel advisory to determine the exact fixed package for each deployed distribution and kernel branch.
• Reboot systems after applying the fixed kernel and verify that the active booted kernel is the patched version.
• Restrict untrusted local code execution on affected hosts until patched, since exploitation likely requires triggering a specific kernel memory-access path.
• Add monitoring for kernel exception loops, unexplained s390 secure execution hangs, watchdog resets, and repeated secure storage access fault messages.
• Prepare operational recovery steps for affected platforms, including out-of-band console access and controlled reboot procedures if a host becomes unresponsive.