Cloudanix VulnDB

CVE-2026-98373

None

CVSS

—

EPSS

0.2%

Published

Oct 7, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how Linux handles moving certain large memory mappings can cause the system to crash unexpectedly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Incorrect address advancement in move_hugetlb_page_tables() during mremap() of hugetlb mappings causes source and destination offsets to diverge when skipping absent page tables, resulting in out-of-bounds page table access and kernel panic on x86-64.

Why it matters to the business

Systems using huge pages and mremap operations may experience unexpected kernel crashes, leading to service disruption and potential data loss in memory-intensive workloads such as databases and virtualization.

How an attack unfolds

An attacker with local code execution crafts a sequence of mremap operations on hugetlb-backed memory regions that trigger the offset miscalculation in move_hugetlb_page_tables, advancing the destination address too far and inducing a kernel panic.

How to fix it

Apply the upstream kernel patch that ensures the destination address is advanced exactly by the same distance as the source address; rebuild and deploy the corrected kernel image.

How to confirm the fix worked

Confirm the corrected move_hugetlb_page_tables implementation is present in the running kernel source or binary, then execute available reproducers to verify no panic occurs under the previously triggering conditions.

Typical attack path

  1. Obtain local execution on a Linux system configured with hugetlb support
  2. Allocate hugetlb-backed memory regions
  3. Perform mremap calls that cause the source page table to be absent or unshared
  4. Trigger the faulty address advancement logic leading to panic

How to detect it

Review kernel logs for oops or panic messages referencing hugetlb and mremap around the time of any observed instability; no specific post-exploitation artifacts are known.

What your security team should do

  • Prioritize kernel upgrade on systems that use hugetlb and mremap
  • Monitor for kernel oops or panic reports involving hugetlb and mremap
  • Restrict untrusted local code execution where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: preserve mremap address delta when skipping page tables move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table. The common loop increment then steps to the first entry in the next page table. However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong. The destination address must be advanced only by the same amount as the source address. If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues. Fix this by advancing the destination address by the source advance distance. With a reproducer, we were able to trigger a kernel panic on x86-64. With this fix in place, we can no longer reproduce the issue.

Affected packages

Ecosystem Package Introduced Fixed