Cloudanix VulnDB

CVE-2025-39992

None

CVSS

—

EPSS

0.2%

Published

Oct 15, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can cause the whole computer to crash when certain memory-swapping operations happen at the same time as creating new processes.

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

What it actually does

Kernel NULL pointer dereference (OOPS) in unuse_mm() during swapoff when a partially-initialized VMA tree containing XA_ZERO_ENTRY markers from a failed fork() dup_mmap() is traversed.

Why it matters to the business

Unprivileged local users can trigger kernel crashes on systems performing swapoff while processes are forking, causing denial of service and potential data loss from abrupt termination; the issue affects many Linux distributions and downstream packages with moderate prevalence.

How an attack unfolds

An attacker triggers concurrent fork() on a process (causing a fatal signal that leaves XA_ZERO_ENTRY markers) while swapoff runs on the same mm_struct added to the mmlist; unuse_mm() then dereferences the zero entry as a VMA, producing the NULL dereference. No named threat actors are associated.

How to fix it

Upgrade to a fixed kernel containing commit 4e5f060d7347466f77aaff1c0d5a6c4f1fb217ac or later; for SUSE Linux Enterprise Server 12 LTSS apply kgraft-patch-SLE12_Update_30 or newer. Reboot after patching and verify MMF_UNSTABLE checks are present.

How to confirm the fix worked

Confirm kernel version contains the listed commit; attempt to reproduce the race under controlled conditions or inspect mm/mmap.c and swapfile.c for the MMF_UNSTABLE guard in dup_mmap() and unuse_mm().

Typical attack path

  1. Local attacker starts or influences a process undergoing fork()
  2. Fatal signal aborts VMA duplication leaving XA_ZERO_ENTRY markers
  3. Attacker or system triggers swapoff on the affected mm
  4. unuse_mm() traverses the unstable tree and crashes the kernel

How to detect it

Search kernel logs for "Unable to handle kernel NULL pointer dereference" combined with addresses near 0x446 or "level 1 translation fault" during swapoff activity; inspect dmesg and syslog for unuse_mm stack traces on systems running older kernels.

What your security team should do

  • Apply the fixed kernel versions immediately on all affected systems
  • Prioritize reboot of high-availability or swap-enabled servers
  • Monitor for kernel oops logs indicating VMA zero-entry dereference until patched

The record

In the Linux kernel, the following vulnerability has been resolved: mm: swap: check for stable address space before operating on the VMA It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.8.0 6.12.51
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.6.1.160000.2.4
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.7.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.7.1
openSUSE:Tumbleweed kernel-source 0 6.17.5-1.1
openSUSE:Tumbleweed kernel-source-longterm 0 6.18.16-1.1

Related vulnerabilities