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

Coiby Xu
2025-05-11T02:21:06Z

On Fri, May 09, 2025 at 06:35:18PM -0700, Andrew Morton wrote:
>On Fri, 9 May 2025 17:58:01 +0800 Baoquan He <bhe@redhat.com> wrote:
>
>> > The bad commit was introduced in 2021 but only recent gcc-15 supports
>> > __counted_by. That's why we don't see this UBSAN warning until this
>> > year. And although this UBSAN warning is scary enough, fortunately it
>> > doesn't cause a real problem.
>> >
>> > >
>> > > Baoquan, please re-review this?
>> > >
>> > > A -stable backport is clearly required. A Fixes: would be nice, but I
>> > > assume this goes back a long time so it isn't worth spending a lot of
>> > > time working out when this was introduced.
>> >
>> > So I believe the correct fix should be as follows,
>>
>> Thanks for testing and investigation into these. Could you arrange this
>> into formal patches based on your testing and analysis?
>>
>> It would be great if you can include Fuqiang's patch since it has
>> conflict with your LUKS patch. This can facilitate patch merging for
>> Andrew. Thanks in advance.
>
>Yes please, I'm a bit lost here.
>x86-kexec-fix-potential-cmem-ranges-out-of-bounds.patch is not
>presently in mm.git and I'd appreciate clarity on how to resolve the
>conflicts which a new version of
>x86-kexec-fix-potential-cmem-ranges-out-of-bounds.patch will produce.

I'll resolve any conflict between these patches. Before that, I'm not
sure if a separate patch to fix the UBSAN warnings alone is needed to Cc
stable@vger.kernel.org because
1) the UBSAN warnings don't mean there is a real problem;
2) both Fuqiang's patch and my kdump LUKS support patches fix the UBSAN
warnings as a by-product.

It seems the answer largely depends on if the stable tree or longterm
trees need it. Currently, only longterm tree 6.12.28 and the stable tree
6.14.6 have the UBSAN warnings if they are compiled with gcc-15 or
clang-18. Any advice will be appreciated! Thanks!

--
Best regards,
Coiby