linux-kernel - Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem

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: <20231219103928.98465-1-ytcoode@gmail.com>
Date: Tue, 19 Dec 2023 18:39:28 +0800
From: Yuntao Wang <ytcoode@...il.com>
To: fuqiang.wang@...ystack.cn
Cc: bhe@...hat.com,
	dyoung@...hat.com,
	kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	vgoyal@...hat.com,
	ytcoode@...il.com
Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range()

On Tue, 19 Dec 2023 16:55:16 +0800, fuqiang wang <fuqiang.wang@...ystack.cn> wrote:

> Thank you very much for your patient comment. This change does indeed improve
> readability. But as a combination of these two, how do you feel about moving
> crash_setup_memmap_entries() behind vzalloc().

I don't quite understand what you're trying to express.

> The image->elf_load_addr is determined by arch_kexec_locate_mem_hole(), this
> function can ensure that the value is within the range of [crashk_res.start,
> crashk_res.end), but it seems that it cannot guarantee that its value will
> always be equal to crashk_res.start. Perhaps I have some omissions, please
> point them out.

Because elfcorehdr is the first one and only one that allocates memory from the
starting address of crashk_res, and the starting address of crashk_res meets
the alignment requirement of elfcorehdr.

elfcorehdr requires 4k alignment, and the starting address of crashk_res is
16M aligned.

Therefore, image->elf_load_addr should be equal to crashk_res.start.