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.
This v5 is on top of below patch which Andrew has picked to his mm tree.
In there, it happened to get the ubsan warning fixed. But the hunk
doesn't reflect it in the v5 patch.
[PATCH v9 7/8] x86/crash: pass dm crypt keys to kdump kernel
https://lore.kernel.org/all/20250502011246.99238-8-c...@redhat.com/T/#u
--
Best regards,
Coiby
