Message-ID: <2025050107-CVE-2025-37760-6efd@gregkh>
Date: Thu,  1 May 2025 15:07:08 +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-37760: mm/vma: add give_up_on_oom option on modify/merge, use in uffd release

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

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

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

mm/vma: add give_up_on_oom option on modify/merge, use in uffd release

Currently, if a VMA merge fails due to an OOM condition arising on commit
merge or a failure to duplicate anon_vma's, we report this so the caller
can handle it.

However there are cases where the caller is only ostensibly trying a
merge, and doesn't mind if it fails due to this condition.

Since we do not want to introduce an implicit assumption that we only
actually modify VMAs after OOM conditions might arise, add a 'give up on
oom' option and make an explicit contract that, should this flag be set, we
absolutely will not modify any VMAs should OOM arise and just bail out.

Since it'd be very unusual for a user to try to vma_modify() with this flag
set but be specifying a range within a VMA which ends up being split (which
can fail due to rlimit issues, not only OOM), we add a debug warning for
this condition.

The motivating reason for this is uffd release - syzkaller (and Pedro
Falcato's VERY astute analysis) found a way in which an injected fault on
allocation, triggering an OOM condition on commit merge, would result in
uffd code becoming confused and treating an error value as if it were a VMA
pointer.

To avoid this, we make use of this new VMG flag to ensure that this never
occurs, utilising the fact that, should we be clearing entire VMAs, we do
not wish an OOM event to be reported to us.

Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for
his insightful and intelligent analysis of the situation, both of whom were
instrumental in this fix.

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


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

	Issue introduced in 6.12.19 with commit 79636d2981b066acd945117387a9533f56411f6f and fixed in 6.12.25 with commit b906c1ad25adce6ff35be19b65a1aa7d960fe1d7
	Issue introduced in 6.14 with commit 47b16d0462a460000b8f05dfb1292377ac48f3ca and fixed in 6.14.4 with commit c103a75c61648203d731e3b97a6fbeea4003cb15
	Issue introduced in 6.14 with commit 47b16d0462a460000b8f05dfb1292377ac48f3ca and fixed in 6.15-rc3 with commit 41e6ddcaa0f18dda4c3fadf22533775a30d6f72f
	Issue introduced in 6.13.7 with commit 53fd215f7886a1e8dea5a9ca1391dbb697fff601

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-37760
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
	mm/vma.c
	mm/vma.h


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/b906c1ad25adce6ff35be19b65a1aa7d960fe1d7
	https://git.kernel.org/stable/c/c103a75c61648203d731e3b97a6fbeea4003cb15
	https://git.kernel.org/stable/c/41e6ddcaa0f18dda4c3fadf22533775a30d6f72f

Powered by blists - more mailing lists