Cloudanix VulnDB

CVE-2025-68179

None

CVSS

—

EPSS

0.2%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A memory-handling problem on certain IBM mainframe computers running Linux could cause sudden system crashes or data loss, and the issue has been fixed by turning off the problematic optimization.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

The vulnerability permits direct replacement of valid kernel page table entries with other valid entries on s390 without using required invalidation instructions such as ipte/idte or replacement instructions such as crdte/cspg, combined with an empty flush_tlb_all implementation, resulting in TLB inconsistencies when ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP is enabled.

Why it matters to the business

Linux systems on s390 hardware may experience reproducible kernel crashes or data corruption when huge-page vmemmap optimization is active, impacting stability for affected packages and downstream dependents until the optimization is disabled.

How an attack unfolds

An attacker triggers huge-page vmemmap operations on s390 that invoke the HVO code path, causing the kernel to modify active page table entries without the architecture-mandated detour through invalid entries or special instructions, leading to random crashes or corruption.

How to fix it

Update affected packages to the listed fixed versions (node-problem-detector-0.8 and health-checker-0.8 and log-counter-0.8 variants on Chainguard/Wolfi to 0.8.20-r4; Linux kernel to commit 7088465f10816d9425b95740b37c95f082041d76) which disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP on s390.

How to confirm the fix worked

Confirm the kernel configuration or source no longer defines ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP for s390, verify the presence of the disabling commit, and test that enabling the feature no longer produces crashes on s390 hardware.

Typical attack path

  1. Obtain local code execution or trigger memory operations that enable huge TLB pages on s390
  2. Invoke the HVO code path that replaces valid page table entries directly
  3. Observe resulting TLB incoherence causing kernel panic or data corruption

How to detect it

Examine s390 kernel logs and dmesg output for repeated crashes or warnings mentioning TLB flushes, page table modifications, or huge-page vmemmap operations; correlate with processes that allocate large memory regions.

What your security team should do

  • Prioritize updating all listed affected packages to the exact fixed versions provided
  • Verify s390 systems are running kernels containing the disabling change
  • Monitor s390 kernel logs for TLB or page-table related panics until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: s390: Disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP As reported by Luiz Capitulino enabling HVO on s390 leads to reproducible crashes. The problem is that kernel page tables are modified without flushing corresponding TLB entries. Even if it looks like the empty flush_tlb_all() implementation on s390 is the problem, it is actually a different problem: on s390 it is not allowed to replace an active/valid page table entry with another valid page table entry without the detour over an invalid entry. A direct replacement may lead to random crashes and/or data corruption. In order to invalidate an entry special instructions have to be used (e.g. ipte or idte). Alternatively there are also special instructions available which allow to replace a valid entry with a different valid entry (e.g. crdte or cspg). Given that the HVO code currently does not provide the hooks to allow for an implementation which is compliant with the s390 architecture requirements, disable ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP again, which is basically a revert of the original patch which enabled it.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.2.0 6.6.117
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9

Related vulnerabilities