CVE-2026-98373: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-98373 Overview

CVE-2026-98373 is a kernel memory management flaw in the Linux kernel's hugetlb subsystem. The defect lives in move_hugetlb_page_tables(), which optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist. The code incorrectly advances both the source and destination addresses to the last entries in their respective page tables, rather than advancing the destination by the same delta as the source. When source and destination offsets differ, the destination address advances too far, producing follow-up corruption. A user-space reproducer was able to trigger a kernel panic on x86-64.

Critical Impact
Local users invoking mremap() on hugetlb mappings can trigger kernel memory corruption and a system-wide panic (denial of service).

Affected Products

Linux kernel (upstream mm/hugetlb subsystem)
Distributions shipping kernels with move_hugetlb_page_tables() prior to the referenced stable commits
x86-64 systems confirmed to panic under the reproducer; other architectures using hugetlb are implicated

Discovery Timeline

2026-10-07 - CVE-2026-98373 published to NVD
2026-10-07 - Last updated in NVD database

Technical Details for CVE-2026-98373

Vulnerability Analysis

The mremap() syscall relocates virtual memory mappings. For hugetlb mappings, the kernel walks source and destination page tables and copies PTE/PMD entries between them. To avoid unnecessary work, move_hugetlb_page_tables() includes a fast path: when a source page table does not exist (either initially or after unsharing a PMD), the loop skips to the last entry so the common increment lands on the first entry of the next table.

The skip logic incorrectly applies the same "advance to last entry" operation to the destination address. Source and destination mappings do not necessarily share the same intra-page-table offset, so moving both to the last entry desynchronizes them. The destination can jump beyond the intended target range, after which subsequent copies write page table entries into unrelated virtual memory. The fix advances the destination by the same delta as the source, preserving the address relationship.

Root Cause

The root cause is an arithmetic error in a page table skip optimization. The code treats two independent address streams as if they shared an offset, violating the invariant that destination advances must equal source advances.

Attack Vector

Exploitation requires local, unprivileged access to a system with hugetlb mappings available to the attacker. The attacker constructs source and destination virtual regions whose offsets within their respective page tables differ, then invokes mremap() to relocate a hugetlb mapping across a boundary that triggers the skip path. The resulting out-of-bounds page table manipulation panics the kernel; follow-on memory corruption primitives have not been publicly characterized.

No verified exploit code is available. See the upstream fixes referenced in the Linux Kernel Commit 9bdad08 and companion stable backports for the exact code change.

Detection Methods for CVE-2026-98373

Indicators of Compromise

Unexpected kernel panics or oops messages referencing move_hugetlb_page_tables, hugetlb_fault, or mremap in call traces.
Processes invoking mremap() against MAP_HUGETLB or hugetlbfs-backed regions immediately before a crash.
Repeated segmentation faults or VM_BUG_ON warnings in mm/hugetlb.c within dmesg.

Detection Strategies

Collect /var/log/kern.log and dmesg output from Linux fleets and alert on panic signatures containing hugetlb page table functions.
Audit workloads that legitimately use huge pages (databases, JVMs, DPDK applications) and baseline their mremap() behavior to spot anomalies.
Correlate kernel crash telemetry with the uid of the last mremap() caller to surface local attempts to trigger the bug.

Monitoring Recommendations

Enable kdump and persistent crash collection so panic traces are preserved for analysis.
Forward kernel logs to a centralized data lake and alert on new occurrences of hugetlb symbols in oops traces.
Track package and kernel versions across the estate to confirm that patched builds are deployed everywhere hugetlb is enabled.

How to Mitigate CVE-2026-98373

Immediate Actions Required

Inventory Linux hosts with hugetlb support compiled in and identify which ones expose hugetlbfs or MAP_HUGETLB to non-root users.
Deploy the stable kernel update containing the fix as soon as the vendor-provided build is available for your distribution.
Restart affected hosts after patching; the fix is in resident kernel code and requires a reboot or kexec.

Patch Information

The upstream fix adjusts move_hugetlb_page_tables() to advance the destination address by the same delta applied to the source. Review the mainline and stable backports: Linux Kernel Commit 9bdad08, Linux Kernel Commit 850cc4a, Linux Kernel Commit 7a96b0f, and Linux Kernel Commit 480a39b. Apply the kernel package released by your distribution that incorporates these commits.

Workarounds

Restrict access to hugetlbfs mounts and remove MAP_HUGETLB capability from untrusted users where feasible.
Disable transparent and explicit huge pages for workloads that do not require them until a patched kernel is deployed.
Where supported, apply distribution livepatch bundles that address the hugetlb mremap path to avoid an immediate reboot.

bash

# Verify running kernel and hugetlb exposure
uname -r
mount | grep hugetlbfs
cat /proc/sys/vm/nr_hugepages

# Temporarily reduce exposure by zeroing persistent huge pages
sysctl -w vm.nr_hugepages=0