From: sashiko-bot@kernel.org
To: "Wandun Chen" <chenwandun1@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 10/10] loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
Date: Tue, 30 Jun 2026 09:37:01 +0000 [thread overview]
Message-ID: <20260630093701.B24B31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260630074715.4126796-11-chenwandun1@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Concurrent memory hotplug during kexec_file_load() can cause an out-of-bounds write in the `cmem->ranges` array due to a TOCTOU between two lockless passes of `for_each_mem_range()`.
--
commit d8948c2d581027666a36bbb47058ae244b39b8ae
Author: Wandun Chen <chenwandun@lixiang.com>
loongarch: kdump: exclude non-dumpable reserved memory regions from vmcore
This commit applies the arm64 non-dumpable reserved memory filtering to
LoongArch kdump. It uses of_reserved_mem_kdump_nr_ranges() to size the
crash_mem array and of_reserved_mem_kdump_exclude() to drop regions.
> diff --git a/arch/loongarch/kernel/machine_kexec_file.c b/arch/loongarch/kernel/machine_kexec_file.c
> index 5584b798ba464..4b918c3d4a285 100644
> --- a/arch/loongarch/kernel/machine_kexec_file.c
> +++ b/arch/loongarch/kernel/machine_kexec_file.c
[ ... ]
> @@ -67,6 +68,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
> nr_ranges = 2; /* for exclusion of crashkernel region */
> for_each_mem_range(i, &start, &end)
> nr_ranges++;
> + nr_ranges += of_reserved_mem_kdump_nr_ranges();
>
> cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
> if (!cmem)
[Severity: High]
This is a pre-existing issue, but can concurrent memory hotplug during
kexec_file_load() cause an out-of-bounds write in the cmem->ranges array?
If the number of memory regions increases between the first lockless pass
of for_each_mem_range() shown above, and the second lockless pass that
populates the array later in prepare_elf_headers():
for_each_mem_range(i, &start, &end) {
cmem->ranges[cmem->nr_ranges].start = start;
cmem->ranges[cmem->nr_ranges].end = end - 1;
cmem->nr_ranges++;
}
could the second pass write past the allocated cmem->ranges array?
Since kexec_file_load() takes kexec_mutex while memory hotplug uses
mem_hotplug_lock, they can run concurrently. A concurrent addition via
memblock_add_node() could result in writing beyond the bounds of the array.
Should there be bounds checking when adding ranges to the array in the
second pass?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260630074715.4126796-1-chenwandun1@gmail.com?part=10
next prev parent reply other threads:[~2026-06-30 9:37 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 7:47 [PATCH v4 00/10] kdump: reduce vmcore size and capture time Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 7:47 ` [PATCH v4 01/10] kexec/crash: provide crash_exclude_mem_range() stub when CONFIG_CRASH_DUMP=n Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 11:05 ` Pratyush Yadav
2026-06-30 11:05 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 02/10] of: reserved_mem: dedup and relocate reserved-memory messages Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 7:47 ` [PATCH v4 03/10] of: reserved_mem: skip late scan when no regions are reserved Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 8:19 ` sashiko-bot
2026-06-30 7:47 ` [PATCH v4 04/10] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late() Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 7:47 ` [PATCH v4 05/10] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 7:47 ` [PATCH v4 06/10] of: reserved_mem: save /memreserve/ entries into the reserved_mem array Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 7:47 ` [PATCH v4 07/10] of: reserved_mem: add kdump helpers to exclude non-dumpable regions Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 08/10] arm64: kdump: exclude non-dumpable reserved memory regions from vmcore Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 9:04 ` sashiko-bot
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 11:06 ` Pratyush Yadav
2026-06-30 7:47 ` [PATCH v4 09/10] riscv: " Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 9:22 ` sashiko-bot
2026-06-30 11:12 ` Pratyush Yadav
2026-06-30 11:12 ` Pratyush Yadav
2026-06-30 12:00 ` Wandun
2026-06-30 12:00 ` Wandun
2026-06-30 7:47 ` [PATCH v4 10/10] loongarch: " Wandun Chen
2026-06-30 7:47 ` Wandun Chen
2026-06-30 9:37 ` sashiko-bot [this message]
2026-06-30 11:13 ` Pratyush Yadav
2026-06-30 11:13 ` Pratyush Yadav
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=20260630093701.B24B31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=chenwandun1@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.