linux-kernel - Re: [PATCH] crash: fix crashkernel resource shrink

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <01045c4c-a37a-4a31-8787-6483c7b78dad@linux.ibm.com>
Date: Mon, 3 Nov 2025 09:38:27 +0530
From: Sourabh Jain <sourabhjain@...ux.ibm.com>
To: Baoquan He <bhe@...hat.com>, Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, Zhen Lei <thunder.leizhen@...wei.com>,
        kexec@...ts.infradead.org
Subject: Re: [PATCH] crash: fix crashkernel resource shrink



On 03/11/25 08:24, Baoquan He wrote:
> On 11/02/25 at 01:07am, Sourabh Jain wrote:
>> When crashkernel is configured with a high reservation, shrinking its
>> value below the low crashkernel reservation causes two issues:
>>
>> 1. Invalid crashkernel resource objects
>> 2. Kernel crash if crashkernel shrinking is done twice
>>
>> For example, with crashkernel=200M,high, the kernel reserves 200MB of
>> high memory and some default low memory (say 256MB). The reservation
>> appears as:
>>
>> cat /proc/iomem | grep -i crash
>> af000000-beffffff : Crash kernel
>> 433000000-43f7fffff : Crash kernel
>>
>> If crashkernel is then shrunk to 50MB (echo 52428800 >
>> /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:
>> af000000-beffffff : Crash kernel
>>
>> Instead, it should show 50MB:
>> af000000-b21fffff : Crash kernel
>>
>> Further shrinking crashkernel to 40MB causes a kernel crash with the
>> following trace (x86):
>>
>> BUG: kernel NULL pointer dereference, address: 0000000000000038
>> PGD 0 P4D 0
>> Oops: 0000 [#1] PREEMPT SMP NOPTI
>> <snip...>
>> Call Trace: <TASK>
>> ? __die_body.cold+0x19/0x27
>> ? page_fault_oops+0x15a/0x2f0
>> ? search_module_extables+0x19/0x60
>> ? search_bpf_extables+0x5f/0x80
>> ? exc_page_fault+0x7e/0x180
>> ? asm_exc_page_fault+0x26/0x30
>> ? __release_resource+0xd/0xb0
>> release_resource+0x26/0x40
>> __crash_shrink_memory+0xe5/0x110
>> crash_shrink_memory+0x12a/0x190
>> kexec_crash_size_store+0x41/0x80
>> kernfs_fop_write_iter+0x141/0x1f0
>> vfs_write+0x294/0x460
>> ksys_write+0x6d/0xf0
>> <snip...>
>>
>> This happens because __crash_shrink_memory()/kernel/crash_core.c
>> incorrectly updates the crashk_res resource object even when
>> crashk_low_res should be updated.
>>
>> Fix this by ensuring the correct crashkernel resource object is updated
>> when shrinking crashkernel memory.
>>
>> Fixes: 16c6006af4d4 ("kexec: enable kexec_crash_size to support two crash kernel regions")
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Baoquan He <bhe@...hat.com>
>> Cc: Zhen Lei <thunder.leizhen@...wei.com>
>> Cc: kexec@...ts.infradead.org
>> Signed-off-by: Sourabh Jain <sourabhjain@...ux.ibm.com>
>> ---
>>   kernel/crash_core.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 3b1c43382eec..99dac1aa972a 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -373,7 +373,7 @@ static int __crash_shrink_memory(struct resource *old_res,
>>   		old_res->start = 0;
>>   		old_res->end   = 0;
>>   	} else {
>> -		crashk_res.end = ram_res->start - 1;
>> +		old_res->end = ram_res->start - 1;
> It's a code bug, nice catch, thanks.
>
> Acked-by: Baoquan He <bhe@...hat.com>

Thanks for the ack, Baoquan.

- Sourabh Jain