cve/published/2024/CVE-2024-45022.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-45022: mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

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

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

mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

The __vmap_pages_range_noflush() assumes its argument pages** contains
pages with the same page shift.  However, since commit e9c3cda4d86e ("mm,
vmalloc: fix high order __GFP_NOFAIL allocations"), if gfp_flags includes
__GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation
failed for high order, the pages** may contain two different page shifts
(high order and order-0).  This could lead __vmap_pages_range_noflush() to
perform incorrect mappings, potentially resulting in memory corruption.

Users might encounter this as follows (vmap_allow_huge = true, 2M is for
PMD_SIZE):

kvmalloc(2M, __GFP_NOFAIL|GFP_X)
    __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP)
        vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0
            vmap_pages_range()
                vmap_pages_range_noflush()
                    __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens

We can remove the fallback code because if a high-order allocation fails,
__vmalloc_node_range_noprof() will retry with order-0.  Therefore, it is
unnecessary to fallback to order-0 here.  Therefore, fix this by removing
the fallback code.

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


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

	Issue introduced in 6.1.95 with commit fe5c2bdcb14c8612eb5e7a09159801c7219e9ac4 and fixed in 6.1.107 with commit fd1ffbb50ef4da5e1378a46616b6d7407dc795da
	Issue introduced in 6.3 with commit e9c3cda4d86e56bf7fe403729f38c4f0f65d3860 and fixed in 6.6.48 with commit de7bad86345c43cd040ed43e20d9fad78a3ee59f
	Issue introduced in 6.3 with commit e9c3cda4d86e56bf7fe403729f38c4f0f65d3860 and fixed in 6.10.7 with commit c91618816f4d21fc574d7577a37722adcd4075b2
	Issue introduced in 6.3 with commit e9c3cda4d86e56bf7fe403729f38c4f0f65d3860 and fixed in 6.11 with commit 61ebe5a747da649057c37be1c37eb934b4af79ca

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-45022
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/vmalloc.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/fd1ffbb50ef4da5e1378a46616b6d7407dc795da
	https://git.kernel.org/stable/c/de7bad86345c43cd040ed43e20d9fad78a3ee59f
	https://git.kernel.org/stable/c/c91618816f4d21fc574d7577a37722adcd4075b2
	https://git.kernel.org/stable/c/61ebe5a747da649057c37be1c37eb934b4af79ca