cve/published/2024/CVE-2024-53096.mbox

From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: <linux-cve-announce@vger.kernel.org>
Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: CVE-2024-53096: mm: resolve faulty mmap_region() error path behaviour

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

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

mm: resolve faulty mmap_region() error path behaviour

The mmap_region() function is somewhat terrifying, with spaghetti-like
control flow and numerous means by which issues can arise and incomplete
state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late
in the process of mapping a VMA, which forms the basis of recently
observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of
checks earlier in the code, simplifying things by moving the core of the
logic into a static internal function __mmap_region().

Doing this allows us to perform a number of checks up front before we do
any real work, and allows us to unwind the writable unmap check
unconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE
validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed
   memory hook, allowing us to exit early and avoid having to perform
   complicated and error-prone close/free logic. We carefully free
   iterator state on both success and error paths.

2. The enclosing mmap_region() function handles the mapping_map_writable()
   logic early. Previously the logic had the mapping_map_writable() at the
   point of mapping a newly allocated file-backed VMA, and a matching
   mapping_unmap_writable() on success and error paths.

   We now do this unconditionally if this is a file-backed, shared writable
   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however
   doing so does not invalidate the seal check we just performed, and we in
   any case always decrement the counter in the wrapper.

   We perform a debug assert to ensure a driver does not attempt to do the
   opposite.

3. We also move arch_validate_flags() up into the mmap_region()
   function. This is only relevant on arm64 and sparc64, and the check is
   only meaningful for SPARC with ADI enabled. We explicitly add a warning
   for this arch if a driver invalidates this check, though the code ought
   eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close
the VMA on error paths, as we place all checks which might fail prior to a
call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason
about and more robust.

The Linux kernel CVE team has assigned CVE-2024-53096 to this issue.


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

	Issue introduced in 5.10.150 with commit a3c08c021778dad30f69895e378843e9f423d734 and fixed in 5.10.231 with commit 43323a4e5b3f8ccc08e2f835abfdc7ee9da8f6ed
	Issue introduced in 5.15.75 with commit 43bed0a13a5cdbb314d14f28c2bf2c60eb4e6e1e and fixed in 5.15.174 with commit 44f48eb9a6051826227bbd375446064fb2a43c6c
	Issue introduced in 6.1 with commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 and fixed in 6.1.119 with commit 52c81fd0f5a8bf8032687b94ccf00d13b44cc5c8
	Issue introduced in 6.1 with commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 and fixed in 6.6.63 with commit bdc136e2b05fabcd780fe5f165d154eb779dfcb0
	Issue introduced in 6.1 with commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 and fixed in 6.12 with commit 5de195060b2e251a835f622759550e6202167641
	Issue introduced in 5.19.17 with commit 6757330b1be5b0606125b65ed50caac69bccf9a5
	Issue introduced in 6.0.3 with commit 66f2ed0172af04a89677ae1898600e1264e25800

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-2024-53096
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/mmap.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/43323a4e5b3f8ccc08e2f835abfdc7ee9da8f6ed
	https://git.kernel.org/stable/c/44f48eb9a6051826227bbd375446064fb2a43c6c
	https://git.kernel.org/stable/c/52c81fd0f5a8bf8032687b94ccf00d13b44cc5c8
	https://git.kernel.org/stable/c/bdc136e2b05fabcd780fe5f165d154eb779dfcb0
	https://git.kernel.org/stable/c/5de195060b2e251a835f622759550e6202167641
	https://project-zero.issues.chromium.org/issues/374117290