public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Yuntao Wang <ytcoode@gmail.com>
To: fuqiang.wang@easystack.cn
Cc: bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, vgoyal@redhat.com,
	ytcoode@gmail.com
Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range()
Date: Tue, 19 Dec 2023 13:29:29 +0800	[thread overview]
Message-ID: <20231219052955.40414-1-ytcoode@gmail.com> (raw)
In-Reply-To: <c797bdde-b5a5-4b2b-9106-c1386a0e7516@easystack.cn>

On Tue, 19 Dec 2023 11:50:32 +0800, fuqiang wang <fuqiang.wang@easystack.cn> wrote:
> 在 2023/12/19 10:47, Yuntao Wang 写道:
> 
> > Hi fuqiang,
> >
> > Yesterday, I posted two patches that happen to address the bugs you an Baoquan
> > are currently discussing here, I wasn't aware that you both were also working
> > on fixing these issues.
> >
> > Baoquan suggested I talk to you about it.
> >
> > If you're interested, you can take a look at my patches and review them to see
> > if there are any issues. If everything is fine, and if you're willing, you can
> > also add a 'Reviewed-by' tag there.
> >
> > The following link is for the two patches I posted yesterday:
> >
> > https://lore.kernel.org/lkml/20231218081915.24120-3-ytcoode@gmail.com/t/#u
> >
> > Sincerely,
> > Yuntao
> 
> Hi Yuntao,
> 
> I'm glad you've also noticed this issue. But I'm sorry, I want to solve this
> problem myself because this is my first time posting a patch in the community,
> and I cherish this opportunity very much.

I can truly understand your feelings because I still remember how thrilled I
was when my first patch got merged. So keep it up!

> 
> I have carefully reviewed your patch. There is some changes where my views differ
> from yours:
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index c92d88680dbf..3be46f4b441e 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -282,10 +282,6 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
>       struct crash_memmap_data cmd;
>       struct crash_mem *cmem;
> 
> -    cmem = vzalloc(struct_size(cmem, ranges, 1));
> -    if (!cmem)
> -        return -ENOMEM;
> -
>       memset(&cmd, 0, sizeof(struct crash_memmap_data));
>       cmd.params = params;
> 
> @@ -321,6 +317,11 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
>       }
> 
>       /* Exclude some ranges from crashk_res and add rest to memmap */
> +    cmem = vzalloc(struct_size(cmem, ranges, 1));
> +    if (!cmem)
> +        return -ENOMEM;
> +    cmem->max_nr_ranges = 1;
> +
>       ret = memmap_exclude_ranges(image, cmem, crashk_res.start, crashk_res.end);
>       if (ret)
>           goto out;
> 
> 1. I don't feel very good that you have moved vzalloc() to in front of
> memmap_exclude_ranges. Because if memory allocation fails, there is no need to
> do anything else afterwards.

I moved it here because only memmap_exclude_ranges() and the code below it use cmem.

I think it is a good practice to put related code together, which also improves
code readability.

> 
> 2. The cmem->max_nr_ranges should be set to 2. Because in
> memmap_exclude_ranges, a cmem->ranges[] will be filled in and if a split occurs
> later, another one will be added.

With the current code, image->elf_load_addr should be equal to crashk_res.start,
so split will not occur in crash_exclude_mem_range(). Therefore, setting
cmem->max_nr_ranges to 1 is safe.

> 
> Thanks
> fuqiang

  reply	other threads:[~2023-12-19  5:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27  2:56 [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() fuqiang wang
2023-11-30  7:44 ` Baoquan He
2023-11-30 13:20   ` fuqiang wang
2023-12-13  4:44     ` Baoquan He
2023-12-13 13:10       ` fuqiang wang
2023-12-14  9:17         ` Baoquan He
2023-12-14 10:29     ` Baoquan He
2023-12-18  8:31       ` fuqiang wang
2023-12-19  2:42         ` Yuntao Wang
2023-12-19  2:47         ` Yuntao Wang
2023-12-19  3:50           ` fuqiang wang
2023-12-19  5:29             ` Yuntao Wang [this message]
2023-12-19  8:55               ` fuqiang wang
2023-12-19 10:39                 ` Yuntao Wang
2023-12-19 12:54                   ` fuqiang wang

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=20231219052955.40414-1-ytcoode@gmail.com \
    --to=ytcoode@gmail.com \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=fuqiang.wang@easystack.cn \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox