Re: [PATCH v4] x86/kexec: fix potential cmem->ranges out of bounds

[Baoquan He <bhe@redhat.com>]

On 05/07/25 at 10:59pm, Andrew Morton wrote:
> On Thu, 8 May 2025 12:25:15 +0800 Coiby Xu <coxu@redhat.com> wrote:
> 
> > >
> > >Acked-by: Baoquan He <bhe@redhat.com>
> > 
> > Hi Andrew,
> > 
> > It seems this patch was missed.
> 
> January 2024.  Yes, it's fair to assume that it was missed ;)
> 
> > Will you pick it up?
> 
> Sure.
> 
> > Without this patch,
> > kdump kernel will fail to be loaded by the kexec_file_load,
> > 
> >   [  139.736948] UBSAN: array-index-out-of-bounds in arch/x86/kernel/crash.c:350:25
> >   [  139.742360] index 0 is out of range for type 'range [*]'
> >   [  139.745695] CPU: 0 UID: 0 PID: 5778 Comm: kexec Not tainted 6.15.0-0.rc3.20250425git02ddfb981de8.32.fc43.x86_64 #1 PREEMPT(lazy) 
> >   [  139.745698] Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017
> >   [  139.745699] Call Trace:
> >   [  139.745700]  <TASK>
> >   [  139.745701]  dump_stack_lvl+0x5d/0x80
> >   [  139.745706]  ubsan_epilogue+0x5/0x2b
> >   [  139.745709]  __ubsan_handle_out_of_bounds.cold+0x54/0x59
> >   [  139.745711]  crash_setup_memmap_entries+0x2d9/0x330
> >   [  139.745716]  setup_boot_parameters+0xf8/0x6a0
> >   [  139.745720]  bzImage64_load+0x41b/0x4e0
> >   [  139.745722]  ? find_next_iomem_res+0x109/0x140
> >   [  139.745727]  ? locate_mem_hole_callback+0x109/0x170
> >   [  139.745737]  kimage_file_alloc_init+0x1ef/0x3e0
> >   [  139.745740]  __do_sys_kexec_file_load+0x180/0x2f0
> >   [  139.745742]  do_syscall_64+0x7b/0x160
> >   [  139.745745]  ? do_user_addr_fault+0x21a/0x690
> >   [  139.745747]  ? exc_page_fault+0x7e/0x1a0
> >   [  139.745749]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >   [  139.745751] RIP: 0033:0x7f7712c84e4d
> > 
> 
> Do we know why this has appeared at such a late date?  The reporter
> must be doing something rare.
> 
> Baoquan, please re-review this?
> 
> A -stable backport is clearly required.  A Fixes: would be nice, but I
> assume this goes back a long time so it isn't worth spending a lot of
> time working out when this was introduced.

No need for stable kernel. The UBSAN only warns a potential risk, it
won't happen in reality. I am talking to Coiby, he got it wrong about
the testing result. He saw the UBSAN warning when UBSAN is enabled,
while vmcore is till saved successfully.

> 
> The patch needed a bit of work to apply to current code.  I did the
> below.  It compiles.
> 
> --- a/arch/x86/kernel/crash.c~x86-kexec-fix-potential-cmem-ranges-out-of-bounds
> +++ a/arch/x86/kernel/crash.c
> @@ -165,8 +165,18 @@ static struct crash_mem *fill_up_crash_e
>  	/*
>  	 * Exclusion of crash region and/or crashk_low_res may cause
>  	 * another range split. So add extra two slots here.
> +	 *
> +	 * Exclusion of low 1M may not cause another range split, because the
> +	 * range of exclude is [0, 1M] and the condition for splitting a new
> +	 * region is that the start, end parameters are both in a certain
> +	 * existing region in cmem and cannot be equal to existing region's
> +	 * start or end. Obviously, the start of [0, 1M] cannot meet this
> +	 * condition.
> +	 *
> +	 * But in order to lest the low 1M could be changed in the future,
> +	 * (e.g. [stare, 1M]), add a extra slot.
>  	 */
> -	nr_ranges += 2;
> +	nr_ranges += 3;
>  	cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
>  	if (!cmem)
>  		return NULL;
> @@ -317,9 +327,16 @@ int crash_setup_memmap_entries(struct ki
>  	 * split. So use two slots here.
>  	 */
>  	nr_ranges = 2;
> -	cmem = vzalloc(struct_size(cmem, ranges, nr_ranges));
> +	/*
> +	 * In the current x86 architecture code, the elfheader is always
> +	 * allocated at crashk_res.start. But it depends on the allocation
> +	 * position of elfheader in crashk_res. To avoid potential out of
> +	 * bounds in future, add a extra slot.
> +	 */
> +	cmem = vzalloc(struct_size(cmem, ranges, 2));
>  	if (!cmem)
>  		return -ENOMEM;
> +	cmem->max_nr_ranges = 2;
>  
>  	cmem->max_nr_ranges = nr_ranges;
>  	cmem->nr_ranges = 0;
> _
>