From: Mike Rapoport <rppt@kernel.org>
To: Rik van Riel <riel@surriel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] mm,memblock: reset memblock.reserved to system init state to prevent UAF
Date: Thu, 20 Jul 2023 08:00:47 +0300 [thread overview]
Message-ID: <20230720050047.GL1901145@kernel.org> (raw)
In-Reply-To: <20230719154137.732d8525@imladris.surriel.com>
Hi Ric,
On Wed, Jul 19, 2023 at 03:41:37PM -0400, Rik van Riel wrote:
> The memblock_discard function frees the memblock.reserved.regions
> array, which is good.
>
> However, if a subsequent memblock_free (or memblock_phys_free) comes
> in later, from for example ima_free_kexec_buffer, that will result in
> a use after free bug in memblock_isolate_range.
The use of memblock_phys_free() in ima_free_kexec_buffer() is entirely
bogus and must be fixed. It should be memblock_free_late() there.
> When running a kernel with CONFIG_KASAN enabled, this will cause a
> kernel panic very early in boot. Without CONFIG_KASAN, there is
> a chance that memblock_isolate_range might scribble on memory
> that is now in use by somebody else.
This can't happen because memblock_double_array() uses kmalloc() as soon as
slab_is_available(), so this sentence is misleading.
> Avoid those issues by making sure that memblock_discard points
> memblock.reserved.regions back at the static buffer.
>
> If memblock_discard is called while there is still memory
> in the memblock.reserved type, that will print a warning
> in memblock_remove_region.
>
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
> mm/memblock.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 3feafea06ab2..068289a46903 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -374,6 +374,10 @@ void __init memblock_discard(void)
> kfree(memblock.reserved.regions);
> else
> memblock_free_late(addr, size);
> + /* Reset to prevent UAF from stray frees. */
> + memblock.reserved.regions = memblock_reserved_init_regions;
> + memblock.reserved.cnt = 1;
> + memblock_remove_region(&memblock.reserved, 0);
> }
>
> if (memblock.memory.regions != memblock_memory_init_regions) {
> --
> 2.34.1
>
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2023-07-20 5:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-19 19:41 [PATCH] mm,memblock: reset memblock.reserved to system init state to prevent UAF Rik van Riel
2023-07-20 5:00 ` Mike Rapoport [this message]
2023-07-20 13:15 ` Rik van Riel
2023-07-20 16:25 ` Mike Rapoport
2023-07-28 16:09 ` Guenter Roeck
2023-07-28 16:36 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230720050047.GL1901145@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.