All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: Mike Galbraith <efault@gmx.de>
Cc: LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org
Subject: Re: x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
Date: Fri, 16 Apr 2021 19:07:01 +0800	[thread overview]
Message-ID: <20210416110701.GA3835@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <9efaad2ba042b8791cbe8c3e7cad491fe05e06eb.camel@gmx.de>

Hi Mike,

Thanks for the patch! I suggest always cc kexec list for kexec/kdump
patches.
On 04/15/21 at 07:56pm, Mike Galbraith wrote:
> x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
> 
> [   15.428011] BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
> [   15.428018] Write of size 8 at addr ffffc90000426008 by task kexec/1187
> 
> (gdb) list *crash_setup_memmap_entries+0x17e
> 0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
> 317                                      unsigned long long mend)
> 318     {
> 319             unsigned long start, end;
> 320
> 321             cmem->ranges[0].start = mstart;
> 322             cmem->ranges[0].end = mend;
> 323             cmem->nr_ranges = 1;
> 324
> 325             /* Exclude elf header region */
> 326             start = image->arch.elf_load_addr;
> (gdb)
> 
> We're excluding two ranges, allocate the scratch space we need to do that.

I think 1 range should be fine, have you tested 1?

The code is just excluding the elf header space which will be loaded
first before anything else so I assume it will be just at the start of
the crashkernel resource region.  Thus [a b] after exclude the start
part will be [c b].  But I have not read the code for long time, maybe I
need to double check.

But anyway 2 would be good since the code is obscure we can easily miss
it in the future.  See how other people think.

> 
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> ---
>  arch/x86/kernel/crash.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -337,7 +337,7 @@ int crash_setup_memmap_entries(struct ki
>  	struct crash_memmap_data cmd;
>  	struct crash_mem *cmem;
> 
> -	cmem = vzalloc(sizeof(struct crash_mem));
> +	cmem = vzalloc(sizeof(struct crash_mem)+(2*sizeof(struct crash_mem_range)));

Thanks for the patch, can you try below?
vzalloc(struct_size(cmem, ranges, 2));


>  	if (!cmem)
>  		return -ENOMEM;
> 
> 

Thanks
Dave


WARNING: multiple messages have this Message-ID (diff)
From: Dave Young <dyoung@redhat.com>
To: Mike Galbraith <efault@gmx.de>
Cc: LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>,
	kexec@lists.infradead.org
Subject: Re: x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
Date: Fri, 16 Apr 2021 19:07:01 +0800	[thread overview]
Message-ID: <20210416110701.GA3835@dhcp-128-65.nay.redhat.com> (raw)
In-Reply-To: <9efaad2ba042b8791cbe8c3e7cad491fe05e06eb.camel@gmx.de>

Hi Mike,

Thanks for the patch! I suggest always cc kexec list for kexec/kdump
patches.
On 04/15/21 at 07:56pm, Mike Galbraith wrote:
> x86/crash: fix crash_setup_memmap_entries() KASAN vmalloc-out-of-bounds gripe
> 
> [   15.428011] BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0
> [   15.428018] Write of size 8 at addr ffffc90000426008 by task kexec/1187
> 
> (gdb) list *crash_setup_memmap_entries+0x17e
> 0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322).
> 317                                      unsigned long long mend)
> 318     {
> 319             unsigned long start, end;
> 320
> 321             cmem->ranges[0].start = mstart;
> 322             cmem->ranges[0].end = mend;
> 323             cmem->nr_ranges = 1;
> 324
> 325             /* Exclude elf header region */
> 326             start = image->arch.elf_load_addr;
> (gdb)
> 
> We're excluding two ranges, allocate the scratch space we need to do that.

I think 1 range should be fine, have you tested 1?

The code is just excluding the elf header space which will be loaded
first before anything else so I assume it will be just at the start of
the crashkernel resource region.  Thus [a b] after exclude the start
part will be [c b].  But I have not read the code for long time, maybe I
need to double check.

But anyway 2 would be good since the code is obscure we can easily miss
it in the future.  See how other people think.

> 
> Signed-off-by: Mike Galbraith <efault@gmx.de>
> ---
>  arch/x86/kernel/crash.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -337,7 +337,7 @@ int crash_setup_memmap_entries(struct ki
>  	struct crash_memmap_data cmd;
>  	struct crash_mem *cmem;
> 
> -	cmem = vzalloc(sizeof(struct crash_mem));
> +	cmem = vzalloc(sizeof(struct crash_mem)+(2*sizeof(struct crash_mem_range)));

Thanks for the patch, can you try below?
vzalloc(struct_size(cmem, ranges, 2));


>  	if (!cmem)
>  		return -ENOMEM;
> 
> 

Thanks
Dave


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2021-04-16 11:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 17:56 x86/crash: fix crash_setup_memmap_entries() out-of-bounds access Mike Galbraith
2021-04-16 11:07 ` Dave Young [this message]
2021-04-16 11:07   ` Dave Young
2021-04-16 11:28   ` Mike Galbraith
2021-04-16 11:28     ` Mike Galbraith
2021-04-16 11:47     ` Dave Young
2021-04-16 11:47       ` Dave Young
2021-04-16 12:02       ` [patch] " Mike Galbraith
2021-04-16 12:02         ` Mike Galbraith
2021-04-16 12:16         ` Borislav Petkov
2021-04-16 12:16           ` Borislav Petkov
2021-04-16 13:16           ` Mike Galbraith
2021-04-16 13:16             ` Mike Galbraith
2021-04-16 14:44             ` Borislav Petkov
2021-04-16 14:44               ` Borislav Petkov
2021-04-16 15:13               ` Mike Galbraith
2021-04-16 15:13                 ` Mike Galbraith
2021-04-16 21:44                 ` Thomas Gleixner
2021-04-16 21:44                   ` Thomas Gleixner
2021-04-17  0:05                   ` Mike Galbraith
2021-04-17  0:05                     ` Mike Galbraith
2021-04-19  8:52                     ` Borislav Petkov
2021-04-19  8:52                       ` Borislav Petkov
2021-04-19  9:37                       ` DaveYoung
2021-04-19  9:37                         ` DaveYoung
2021-04-20 18:00         ` [tip: x86/urgent] x86/crash: Fix " tip-bot2 for Mike Galbraith

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=20210416110701.GA3835@dhcp-128-65.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=bhe@redhat.com \
    --cc=efault@gmx.de \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.