Cloudanix VulnDB

CVE-2026-90391

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel test code can make certain test operations loop forever and freeze instead of failing cleanly when a memory area disappears.

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

What it actually does

Incorrect return value in dmirror_fault() causes caller retry loops to spin indefinitely when the mirrored mm has exited, because success is reported despite no page being faulted or device PTE installed.

Why it matters to the business

Test processes or workloads exercising the HMM test module can hang, wasting CPU resources and potentially destabilizing development or test systems until manually terminated.

How an attack unfolds

An attacker with local access triggers dmirror_read or dmirror_write paths after the mirrored mm exits; the faulty success return causes repeated -ENOENT handling and an infinite retry loop, resulting in denial of service.

How to fix it

Apply the upstream fix that changes the return value to -EFAULT when mmget_not_zero fails; rebuild and deploy kernels containing the corrected lib/test_hmm logic.

How to confirm the fix worked

Confirm the source contains the -EFAULT return on mmget_not_zero failure in dmirror_fault; run test_hmm workloads that previously triggered the loop and verify they now terminate with an error instead of hanging.

Typical attack path

  1. Obtain local access to a system running a kernel with the vulnerable test_hmm module loaded.
  2. Invoke dmirror_read or dmirror_write operations that reach dmirror_fault after the target mm has exited.
  3. mmget_not_zero fails but the function returns 0, causing the caller to retry the same address repeatedly.
  4. The loop consumes CPU without progress until the process is killed or the system is rebooted.

How to detect it

Inspect kernel logs and process listings for dmirror-related threads stuck in retry loops; correlate with mm exit events in the test harness; no production exploit artifacts are expected.

What your security team should do

  • Prioritize patching test and development kernels that include the vulnerable module.
  • Disable or remove the test_hmm module from production kernel configurations where feasible.
  • Monitor for long-running dmirror processes consuming unexpected CPU as a temporary detection measure.

The record

In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone dmirror_fault() is called from the dmirror_read() and dmirror_write() retry loops after dmirror_do_read() or dmirror_do_write() finds a missing device page table entry. If the mirrored mm has already exited, mmget_not_zero() fails. The current code returns 0 in that case, which tells the caller that faulting succeeded even though no page was faulted and no device page table entry was installed. The caller then retries the same address, hits -ENOENT again, and can loop forever without making progress. Return -EFAULT instead, so the ioctl fails when the mirrored mm is no longer faultable.

Affected packages

Ecosystem Package Introduced Fixed