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

Coiby Xu
2025-05-29T02:18:57Z

On Tue, May 20, 2025 at 05:13:28PM +0800, Coiby Xu wrote:
>On Mon, May 19, 2025 at 10:34:39PM +0800, Baoquan He wrote:
>>On 05/19/25 at 07:19am, Kees Cook wrote:
>>>On Mon, May 19, 2025 at 09:22:30AM +0800, Baoquan He wrote:
>[...]
>>>> > I went back through the thread and the referenced threads and I can't
>>>> > find any details on the USBAN splat. Can that please get reproduced in a
>>>> > commit log? That would help understand if it's a false positive or not.
>>>>
>>>>
>>>> The original patch is trying to fix a potential issue in which a memory
>>>> range is split, while the sub-range split out is always on top of the
>>>> entire memory range, hence no risk.
>>>>
>>>> Later, we encountered a UBSAN warning around the above memory range
>>>> splitting code several times. We found this patch can mute the warning.
>>>>
>>>> Please see below UBSAN splat trace report from Coiby:
>>>> https://lore.kernel.org/all/4de3c2onosr7negqnfhekm4cpbklzmsimgdfv33c52dktqpza5@z5pb34ghz4at/T/#u
>>>
>>>Ah-ha! Thanks for the link.
>>>
>>>> Later, Coiby got the root cause from investigation, please see:
>>>> https://lore.kernel.org/all/2754f4evjfumjqome63bc3inqb7ozepemejn2lcl57ryio2t6k@35l3tnn73gei/T/#u
>>>
>>>Looking at https://lore.kernel.org/all/aBxfflkkQXTetmbq@MiWiFi-R3L-srv/
>>>it seems like this actually turned out to be a legitimate overflow
>>>detection? I.e. the fix isn't silencing a false positive, but rather
>>>allocating enough space?
>
>The words "out of bounds" in the patch subject are kind of misleading
>because the patch is outdated. A later merged commit 6dff31597264
>("crash_core: fix and simplify the logic of crash_exclude_mem_range()")
>has actually fixed out-of-bound access issue as illustrated in
>https://lore.kernel.org/kexec/ZXrY7QbXAlxydsSC@MiWiFi-R3L-srv/ Current
>crash_exclude_mem_range simply returns -ENOMEM when there is no
>enough space to hold split ranges (I'll post a patch to prove the
>correctness of crash_exclude_mem_range by reasoning about the code and
>including a thorough unit tests). So I'll change the subject to "fix
>potential cmem->ranges out of memory" in the upcoming patch.

The kdump LUKS support patches which fix the UBSAN warnings as a
byproduct are now in the Andrew's mm-nonmm-stable tree. Can I assume
it's not appropriate to re-send a new version of kdump LUKS support
patches which includes a separate patch to fix the UBSAN warnings alone?
If that's the case, I can send a single patch to the stable tree if the
stable tree requires an upstream commit already in Linus's tree.

--
Best regards,
Coiby