On Fri, May 09, 2025 at 05:58:01PM +0800, Baoquan He wrote:
On 05/09/25 at 12:04pm, Coiby Xu wrote:
On Wed, May 07, 2025 at 10:59:59PM -0700, Andrew Morton wrote:
[...]
>
> Do we know why this has appeared at such a late date? The reporter
> must be doing something rare.
The UBSAN warning happens because flexible array members annotated with
__counted_by are accessed without assigning an array element count i.e.
crash_mem->ranges[0] is accessed without setting max_nr_ranges after
vzalloc,
// include/linux/crash_core.h
struct crash_mem {
unsigned int max_nr_ranges;
unsigned int nr_ranges;
struct range ranges[] __counted_by(max_nr_ranges);
};
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.
Sure, I'll ask Andrew if a separate patch is needed because both my
Fuqiang's patch and the kdump LUKS support patches fix the UBSAN warning
as a by-product. And I'll resolve any conflict. Meanwhile, I'll need
more time to investigate Fuqiang's patch. For example, because of
commit 6dff31597264 ("crash_core: fix and simplify the logic of
crash_exclude_mem_range()"), cmem->ranges out of bounds doesn't seem to
happen any more because now -ENOMEM will be returned instead.
--
Best regards,
Coiby
