linux-cve-announce - CVE-2025-39899: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025100117-CVE-2025-39899-3921@gregkh>
Date: Wed,  1 Oct 2025 09:43:23 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-39899: mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE

With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using
kmap_local_page(), which requires unmapping in Last-In-First-Out order.

The current code maps dst_pte first, then src_pte, but unmaps them in the
same order (dst_pte, src_pte), violating the LIFO requirement.  This
causes the warning in kunmap_local_indexed():

  WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c
  addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)

Fix this by reversing the unmap order to respect LIFO ordering.

This issue follows the same pattern as similar fixes:
- commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")
- commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")

Both of which addressed the same fundamental requirement that kmap_local
operations must follow LIFO ordering.

The Linux kernel CVE team has assigned CVE-2025-39899 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.8 with commit adef440691bab824e39c1b17382322d195e1fab0 and fixed in 6.12.46 with commit b051f707018967ea8f697d790a1ed8c443f63812
	Issue introduced in 6.8 with commit adef440691bab824e39c1b17382322d195e1fab0 and fixed in 6.16.6 with commit bd1ee62759d0bd4d6b909731c076c230ac89d61e
	Issue introduced in 6.8 with commit adef440691bab824e39c1b17382322d195e1fab0 and fixed in 6.17 with commit 9614d8bee66387501f48718fa306e17f2aa3f2f3

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-39899
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	mm/userfaultfd.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/b051f707018967ea8f697d790a1ed8c443f63812
	https://git.kernel.org/stable/c/bd1ee62759d0bd4d6b909731c076c230ac89d61e
	https://git.kernel.org/stable/c/9614d8bee66387501f48718fa306e17f2aa3f2f3