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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <gxysezp2tc6qtb3o3wpdsk7k4aijxontf3ozfnhn76giobkefe@v2vkfov2tcck>
Date: Tue, 20 May 2025 17:13:28 +0800
From: Coiby Xu <coxu@...hat.com>
To: Kees Cook <kees@...nel.org>, Baoquan He <bhe@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	fuqiang wang <fuqiang.wang@...ystack.cn>, Vivek Goyal <vgoyal@...hat.com>, Dave Young <dyoung@...hat.com>, 
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH v4] x86/kexec: fix potential cmem->ranges out of bounds

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-coxu@redhat.com/T/#u
>

-- 
Best regards,
Coiby