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

Coiby Xu
2025-05-08T04:26:28Z

On Tue, Jan 09, 2024 at 11:46:15AM +0800, Baoquan He wrote:
>On 01/08/24 at 09:06pm, fuqiang wang wrote:
>> In memmap_exclude_ranges(), elfheader will be excluded from crashk_res.
>> In the current x86 architecture code, the elfheader is always allocated
>> at crashk_res.start. It seems that there won't be a new split range.
>> But it depends on the allocation position of elfheader in crashk_res. To
>> avoid potential out of bounds in future, add a extra slot.
>>
>> The similar issue also exists in fill_up_crash_elf_data(). The range to
>> be excluded is [0, 1M], start (0) is special and will not appear in the
>> middle of existing cmem->ranges[]. But in cast the low 1M could be
>> changed in the future, add a extra slot too.
>>
>> Previously discussed link:
>> [1] https://lore.kernel.org/kexec/ZXk2oBf%2FT1Ul6o0c@MiWiFi-R3L-srv/
>> [2] https://lore.kernel.org/kexec/273284e8-7680-4f5f-8065-c5d780987e59@easystack.cn/
>> [3] https://lore.kernel.org/kexec/ZYQ6O%2F57sHAPxTHm@MiWiFi-R3L-srv/
>>
>> Signed-off-by: fuqiang wang <fuqiang.wang@easystack.cn>
>> ---
>> arch/x86/kernel/crash.c | 21 +++++++++++++++++++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
>> index b6b044356f1b..d21592ad8952 100644
>> --- a/arch/x86/kernel/crash.c
>> +++ b/arch/x86/kernel/crash.c
>> @@ -149,8 +149,18 @@ static struct crash_mem *fill_up_crash_elf_data(void)
>> /*
>> * 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;
>> @@ -282,9 +292,16 @@ 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));
>> + /*
>> + * 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;
>
>LGTM, thx
>
>Acked-by: Baoquan He <bhe@redhat.com>

Hi Andrew,

It seems this patch was missed. Will you pick it up? 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

Thanks!

--
Best regards,
Coiby