All of lore.kernel.org
 help / color / mirror / Atom feed
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 19:25:22 +0300	[thread overview]
Message-ID: <20230720162522.GO1901145@kernel.org> (raw)
In-Reply-To: <20230719154137.732d8525@imladris.surriel.com>

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.
> 
> 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.
> 
> 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.

I'm going to apply this with the last paragraph rewritten as 

If memblock_free is called after memblock memory is discarded, 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.


  parent reply	other threads:[~2023-07-20 16:25 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
2023-07-20 13:15   ` Rik van Riel
2023-07-20 16:25 ` Mike Rapoport [this message]
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=20230720162522.GO1901145@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.