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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250507231003.c11c4b90d6a2b1f6ddce792e@linux-foundation.org>
Date: Wed, 7 May 2025 23:10:03 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: fuqiang wang <fuqiang.wang@...ystack.cn>
Cc: Baoquan He <bhe@...hat.com>, Vivek Goyal <vgoyal@...hat.com>, Dave Young
 <dyoung@...hat.com>, kexec@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Coiby Xu <coxu@...hat.com>
Subject: Re: [PATCH v4] x86/kexec: fix potential cmem->ranges out of bounds

On Mon,  8 Jan 2024 21:06:47 +0800 fuqiang wang <fuqiang.wang@...ystack.cn> 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/

So.

When I merge this ancient fix against mainline, it goes OK.

When I merge Coiby's "x86/crash: pass dm crypt keys to kdump kernel"
on top of this fix,  things do not go OK.

Here is what I did:

int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
{
	unsigned int nr_ranges = 0;
	int i, ret = 0;
	unsigned long flags;
	struct e820_entry ei;
	struct crash_memmap_data cmd;
	struct crash_mem *cmem;

	/*
	 * Using random kexec_buf for passing dm crypt keys may cause a range
	 * split. So use two slots here.
	 */
	nr_ranges = 2;

	/*
	 * 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, nr_ranges));
	if (!cmem)
		return -ENOMEM;

	cmem->max_nr_ranges = nr_ranges;
	cmem->nr_ranges = 0;

	memset(&cmd, 0, sizeof(struct crash_memmap_data));

Please triple check this, I changed a few things.