CVE-2026-64369: Linux Kernel s390 DoS Vulnerability

CVE-2026-64369 Overview

CVE-2026-64369 affects the Linux kernel on the IBM s390 architecture. The vulnerability stems from the interaction between load_unaligned_zeropad() and the do_secure_storage_access() exception handler. When pages are donated to the Ultravisor for secure execution, unaligned reads that cross page boundaries can trigger exceptions the handler does not resolve correctly. The result is an endless exception loop on affected s390 systems running Confidential Computing workloads. Kernel maintainers resolved the issue by reverting DCACHE_WORD_ACCESS support on s390 as a temporary workaround until secure storage access exception handling is properly fixed.

Critical Impact
An unresolvable exception loop can occur when load_unaligned_zeropad() reads memory pages donated to the Ultravisor, causing denial of service on s390 secure execution guests.

Affected Products

Linux kernel on IBM s390 / s390x architecture
Kernel builds with DCACHE_WORD_ACCESS enabled on s390
s390 Secure Execution guests using Ultravisor-donated memory

Discovery Timeline

2026-07-25 - CVE-2026-64369 published to the National Vulnerability Database
2026-07-25 - Last updated in NVD database

Technical Details for CVE-2026-64369

Vulnerability Analysis

The Linux kernel provides load_unaligned_zeropad() as a fast-path helper used by dcache word-at-a-time string operations. The function reads eight bytes from unaligned addresses and may cross a page boundary. If the second page is not mapped, the kernel catches the resulting fault and returns zero-padded data. This behavior is correct on architectures where the page-fault handler cleanly reports and dismisses the exception.

On s390, pages can be donated to the Ultravisor to support IBM Secure Execution, a Confidential Computing feature. Accessing such a donated page from the host kernel raises a secure storage access exception, which is handled by do_secure_storage_access(). The handler does not correctly dismiss the exception when it originates from load_unaligned_zeropad(), so the offending instruction retries and re-triggers the fault indefinitely.

A prior fix, commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory"), attempted to address the issue but proved insufficient. Maintainers reverted DCACHE_WORD_ACCESS support on s390 as a temporary workaround. The load_unaligned_zeropad() implementation itself is correct; the defect lies in s390 exception handling for donated memory.

Root Cause

The root cause is incomplete handling of secure storage access exceptions in the s390 do_secure_storage_access() path when the faulting instruction is a speculative unaligned read across a page boundary. Combined with DCACHE_WORD_ACCESS, this produces an endless exception loop [CWE-755: Improper Handling of Exceptional Conditions].

Attack Vector

The defect is triggered by legitimate dcache operations that invoke load_unaligned_zeropad() against memory adjacent to Ultravisor-donated pages. Any workload path exercising word-at-a-time string handling near such boundaries can cause the host kernel to enter an unrecoverable exception loop, resulting in a denial of service on the affected s390 system. No specific exploit code is required beyond triggering the code path on a vulnerable Secure Execution configuration.

See the upstream kernel commits for the revert and prior fix attempts: kernel.org commit 37540b8c, kernel.org commit be79d285, kernel.org commit c9480690, and kernel.org commit c9e0f151.

Detection Methods for CVE-2026-64369

Indicators of Compromise

Kernel logs on s390 hosts showing repeated secure storage access exceptions originating from the same instruction pointer.
s390 Secure Execution guests becoming unresponsive or CPUs pinned at 100% in kernel mode without forward progress.
Soft lockup warnings on s390 systems referencing dcache or load_unaligned_zeropad code paths.

Detection Strategies

Inventory s390 and s390x kernels and identify builds compiled with DCACHE_WORD_ACCESS enabled that predate the revert commits listed in the kernel references.
Compare running kernel versions against the fixed stable trees referenced by the upstream commits and flag hosts still on vulnerable revisions.
Correlate host and guest telemetry to identify Secure Execution guests that exhibit repeated fault-handler entries with no resolution.

Monitoring Recommendations

Forward s390 kernel dmesg output and machine check records to a centralized log platform for pattern analysis.
Alert on sustained kernel-mode CPU utilization on s390 hosts running Secure Execution workloads.
Track patch state of Linux kernels across the s390 fleet as part of standard vulnerability management.

How to Mitigate CVE-2026-64369

Immediate Actions Required

Upgrade affected s390 Linux kernels to a stable release containing the DCACHE_WORD_ACCESS revert referenced in the upstream commits.
Prioritize patching hosts running IBM Secure Execution guests, since these are the systems that can enter the unrecoverable exception loop.
Reboot into the patched kernel and validate that s390 systems boot cleanly with the revert applied.

Patch Information

The upstream fix reverts DCACHE_WORD_ACCESS support on s390. Apply the patched kernel from the relevant stable branch. The relevant commits are available at kernel.org commit 37540b8c, kernel.org commit be79d285, kernel.org commit c9480690, and kernel.org commit c9e0f151. Consume the fix through your Linux distribution vendor when available.

Workarounds

Rebuild the s390 kernel with DCACHE_WORD_ACCESS disabled if a patched vendor kernel is not yet available.
Avoid deploying Secure Execution workloads on vulnerable kernels until the fixed build is installed.
Restrict access to s390 Secure Execution guests to reduce the likelihood of triggering the affected code path.

bash

# Verify running kernel version and architecture on s390 hosts
uname -srm

# Confirm the fix commit is present in the kernel source tree
git log --oneline | grep -E '37540b8c|be79d285|c9480690|c9e0f151'

# Check kernel config for DCACHE_WORD_ACCESS status
zcat /proc/config.gz | grep DCACHE_WORD_ACCESS