mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jinjie Ruan <ruanjinjie@huawei.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>, <maddy@linux.ibm.com>,
	<mpe@ellerman.id.au>, <npiggin@gmail.com>, <chleroy@kernel.org>,
	<rppt@kernel.org>, <baoquan.he@linux.dev>,
	<hbathini@linux.ibm.com>, <adityag@linux.ibm.com>,
	<ritesh.list@gmail.com>, <bauerman@linux.ibm.com>,
	<linuxppc-dev@lists.ozlabs.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] powerpc/kexec_file: Prevent kexec range truncation
Date: Wed, 29 Jul 2026 14:26:53 +0800	[thread overview]
Message-ID: <3a296aeb-d978-4460-bc7d-0500873127fc@huawei.com> (raw)
In-Reply-To: <12df5a43-792a-45a9-9524-fa974cc1ce62@linux.ibm.com>



在 2026/7/29 12:43, Sourabh Jain 写道:
> 
> 
> On 29/07/26 06:59, Jinjie Ruan wrote:
>> Sashiko AI review pointed out the following issue.
>>
>> The __merge_memory_ranges() function incorrectly handles overlapping
>> memory ranges when merging them. Although sort_memory_ranges() sorts all
>> ranges by their start address in ascending order beforehand, the merge
>> logic remains defective in two ways:
>>
>> 1. It compares the current range's start against the previous element
>> (i-1)
>>     instead of the running target index (idx)
>>
>> 2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'.
>>
>> This logic flaw leads to critical memory truncation when a larger memory
>> range completely subsumes subsequent smaller ranges.
>>
>> For example, consider a sorted input array with three ranges:
>>    Range A (idx=0): [0x1000 - 0x9000]
>>    Range B (i=1):   [0x2000 - 0x5000] (completely inside Range A)
>>    Range C (i=2):   [0x6000 - 0x8000] (completely inside Range A)
>>
>> 1. When i=1 (Range B):
>>     ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE.
>>     The code executes: ranges[0].end = ranges[1].end, which erroneously
>>     shrinks Range A's end from 0x9000 down to 0x5000.
>>
>> 2. When i=2 (Range C):
>>     ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE.
>>     The code falls into the else block, creating a broken new range.
>>
>> As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 -
>> 0x9000]
>> are completely lost from the kexec exclude lists, potentially allowing
>> the crash kernel to overwrite active memory, causing data corruption
>> or crashes.
>>
>> Fix this by ensuring the start of the current range is compared
>> against the
>> end of the active merged range (idx), and use max() to safely prevent the
>> outer boundary from being truncated.
>>
>> Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: stable@vger.kernel.org
>> Fixes: 180adfc532a8 ("powerpc/kexec_file: Add helper functions for
>> getting memory ranges")
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>>   arch/powerpc/kexec/ranges.c | 12 +++++-------
>>   1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/kexec/ranges.c b/arch/powerpc/kexec/ranges.c
>> index e5fea23b191b..539061d14a77 100644
>> --- a/arch/powerpc/kexec/ranges.c
>> +++ b/arch/powerpc/kexec/ranges.c
>> @@ -21,6 +21,7 @@
>>   #include <linux/of.h>
>>   #include <linux/slab.h>
>>   #include <linux/memblock.h>
>> +#include <linux/minmax.h>
>>   #include <linux/crash_core.h>
>>   #include <asm/sections.h>
>>   #include <asm/kexec_ranges.h>
>> @@ -105,19 +106,16 @@ static void __merge_memory_ranges(struct
>> crash_mem *mem_rngs)
>>       struct range *ranges;
>>       int i, idx;
>>   -    if (!mem_rngs)
>> +    if (!mem_rngs || mem_rngs->nr_ranges <= 1)
>>           return;
> 
> Although the below loop handles this but it is good to return early when
> there is
> only range.
> 
>>         idx = 0;
>> -    ranges = &(mem_rngs->ranges[0]);
>> +    ranges = mem_rngs->ranges;
>>       for (i = 1; i < mem_rngs->nr_ranges; i++) {
>> -        if (ranges[i].start <= (ranges[i-1].end + 1))
>> -            ranges[idx].end = ranges[i].end;
>> +        if (ranges[i].start <= (ranges[idx].end + 1))
>> +            ranges[idx].end = max(ranges[idx].end, ranges[i].end);
> 
> Yeah this changes is needed.
> 
>>           else {
>>               idx++;
>> -            if (i == idx)
>> -                continue;
> 
> Do we really need to remove the above condition?
> 
> Isn't this condition is helpful till we find an overlap?

Hi Sourabh,

I believe there is no functional change here. The else branch itself
already indicates that there will be no overlap this time, so we can
safely use ranges[i] as the next memory region.

Whether we remove it or keep it is fine.

> 
> - Sourabh Jain
> 
>> -
>>               ranges[idx] = ranges[i];
>>           }
>>       }
> 


  reply	other threads:[~2026-07-29  6:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  1:29 [PATCH v2 0/3] powerpc/kexec_file: Fix some bugs Jinjie Ruan
2026-07-29  1:29 ` [PATCH v2 1/3] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() Jinjie Ruan
2026-07-29  1:29 ` [PATCH v2 2/3] powerpc/kexec_file: Fix null-ptr-def in extra size calculation Jinjie Ruan
2026-07-29  4:01   ` Sourabh Jain
2026-07-29  1:29 ` [PATCH v2 3/3] powerpc/kexec_file: Prevent kexec range truncation Jinjie Ruan
2026-07-29  4:43   ` Sourabh Jain
2026-07-29  6:26     ` Jinjie Ruan [this message]
2026-07-29  6:44       ` Sourabh Jain
2026-07-29  7:06         ` Jinjie Ruan
2026-07-29  8:18           ` Sourabh Jain
2026-08-03  6:57 ` [PATCH v2 0/3] powerpc/kexec_file: Fix some bugs Madhavan Srinivasan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a296aeb-d978-4460-bc7d-0500873127fc@huawei.com \
    --to=ruanjinjie@huawei.com \
    --cc=adityag@linux.ibm.com \
    --cc=baoquan.he@linux.dev \
    --cc=bauerman@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=hbathini@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ritesh.list@gmail.com \
    --cc=rppt@kernel.org \
    --cc=sourabhjain@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®