Re: [PATCH] kexec: fix stack buffer overflow in update_purgatory()

[Simon Horman <horms@kernel.org>]

On Tue, Nov 10, 2026 at 08:36:12PM +0800, 张子康  wrote:
> 
> Hi Simon,
> 
> Thanks for your review and for taking the time to share your suggestion — I really appreciate the detailed feedback.
> 
> I did consider adding a die when the 16-segment limit is reached in add_segment_phys_virt, but after looking at the overall design I think the current approach of printing a warning without terminating may be the reasonable one, for two reasons:
> 
> 1. KEXEC_MAX_SEGMENTS in kexec-tools is only an expectation on the userspace tool side. Printing a warning and then letting the kernel perform the final validation and return an error keeps the flow complete. If we changed this to die, kexec-tools would exit before even issuing the system call. Although the outcome is failure either way, what the user sees would be the tool giving up on its own, rather than the kernel explicitly reporting "invalid argument" (EINVAL).
> 
> 2. The value of KEXEC_MAX_SEGMENTS has historically been increased from 8 to 16 in kexec-tools, with KEXEC_SEGMENT_MAX on the kernel side adjusted in tandem. This limit is inherently arbitrary, so in update_purgatory merely avoiding out-of-bounds writes and emitting a warning that the region limit has been reached — and then deferring final validation to the kernel — is more flexible than a hard termination, and can accommodate the actual limits of different kernel versions.
> 
> Please let me know what you think.

Hi Zikang,

Thanks for the response, likewise much appreciated.

I understand what you are saying about the desirability of the Kernel
enforcing the kernel limit. But to my mind we the kexec-tools limit is also
a limit, even if it has the same value as the kernel limit.  And it is
appropriate for kexec-tools to enforce the limit it has.

I think that if kexec-tools used dynamic buffers, and thus had no limit,
then we could happily leave it up to the kernel to enforce what would then
be the only limit. But I also don't think it's worth moving kexec-tools to
use dynamic buffers to achieve this.

So I do think, given the implementation of kexec-tools, that the approach I
suggested is a good way to go.