Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range()
From: fuqiang wang
Date: Mon Dec 18 2023 - 06:01:23 EST
在 2023/12/14 18:29, Baoquan He 写道:
On 11/30/23 at 09:20pm, fuqiang wang wrote:
On 2023/11/30 15:44, Baoquan He wrote:
On 11/27/23 at 10:56am, fuqiang wang wrote:
When the split happened, judge whether mem->nr_ranges is equal to
mem->max_nr_ranges. If it is true, return -ENOMEM.
The advantage of doing this is that it can avoid array bounds caused by
some bugs. E.g., Before commit 4831be702b95 ("arm64/kexec: Fix missing
extra range for crashkres_low."), reserve both high and low memories for
the crashkernel may cause out of bounds.
On the other hand, move this code before the split to ensure that the
array will not be changed when return error.
If out of array boundary is caused, means the laoding failed, whether
the out of boundary happened or not. I don't see how this code change
makes sense. Do I miss anything?
Thanks
Baoquan
Hi baoquan,
In some configurations, out of bounds may not cause crash_exclude_mem_range()
returns error, then the load will succeed.
E.g.
There is a cmem before execute crash_exclude_mem_range():
cmem = {
max_nr_ranges = 3
nr_ranges = 2
ranges = {
{start = 1, end = 1000}
{start = 1001, end = 2000}
}
}
After executing twice crash_exclude_mem_range() with the start/end params
100/200, 300/400 respectively, the cmem will be:
cmem = {
max_nr_ranges = 3
nr_ranges = 4 <== nr_ranges > max_nr_ranges
ranges = {
{start = 1, end = 99 }
{start = 201, end = 299 }
{start = 401, end = 1000}
{start = 1001, end = 2000} <== OUT OF BOUNDS
}
}
Let me borrow your example and copy them here, but I will switch the
order of start/end params 100/200, 300/400 executing at below:
There is a cmem before execute crash_exclude_mem_range():
cmem = {
max_nr_ranges = 3
nr_ranges = 2
ranges = {
{start = 1, end = 1000}
{start = 1001, end = 2000}
}
}
After executing twice crash_exclude_mem_range() with the start/end params
300/400, the cmem will be:
cmem = {
max_nr_ranges = 3
nr_ranges = 3 <== nr_ranges == max_nr_ranges
ranges = {
{start = 1, end = 299 } i=0
{start = 401, end = 1000} i=1
{start = 1001, end = 2000} i=2
}
}
When it's executing the 100/200 excluding, we have:
cmem = {
max_nr_ranges = 3
nr_ranges = 4 <== nr_ranges > max_nr_ranges
ranges = {
{start = 1, end = 99 } i=0
{start = 401, end = 1000}
{start = 1001, end = 2000}
}
}
Then splitting happened, i == 0, then for loop is broken and jump out.
Then we have the condition checking here:
/* Split happened */
if (i == mem->max_nr_ranges - 1)
return -ENOMEM;
Obviously the conditonal checking is incorrect (given the i == 0 in
above case), it should be
/* Split happened */
if (mem->nr_ranges == mem->max_nr_ranges)
return -ENOMEM;
So, now there are two things which need be combed up in
crash_exclude_mem_range():
1) the above conditional check is incorrect, need be fixed;
2) whether we need have the cmem->ranges[] partly changed, or keep it
unchanged when OOB happened;
Hi baoquan,
I'm sorry, I would like to confirm if I misunderstood the meaning of your
comment or not. What you mean is that you have agreed to merge the patch, but
before that, it needs to be explained in detail in the commit message. Is this
understanding correct?
And also the incorrect handling in crash_setup_memmap_entries():
1) the insufficient array slot in crash_setup_memmap_entries();
2) the uninitialized cmem->max_nr_ranges;
If this patch can be merged, the issue of the uninitialized cmem->max_nr_ranges
must be resolved before the patch is merged because this patch requires a
initialized max_nr_ranges value. I am willing to take on the task of addressing
those issues.
Thanks
fuqiang
When an out of bounds occurs during the second execution, the function will not
return error.
Additionally, when the function returns error, means the load failed. It seems
meaningless to keep the original data unchanged. But in my opinion, this will
make this function more rigorous and more versatile. (However, I am not sure if
it is self-defeating and I hope to receive more suggestions).
Thanks
fuqiang
Signed-off-by: fuqiang wang <fuqiang.wang@xxxxxxxxxxxx>
---
kernel/crash_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index efe87d501c8c..ffdc246cf425 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -611,6 +611,9 @@ int crash_exclude_mem_range(struct crash_mem *mem,
}
if (p_start > start && p_end < end) {
+ /* Split happened */
+ if (mem->nr_ranges == mem->max_nr_ranges)
+ return -ENOMEM;
/* Split original range */
mem->ranges[i].end = p_start - 1;
temp_range.start = p_end + 1;
@@ -626,9 +629,6 @@ int crash_exclude_mem_range(struct crash_mem *mem,
if (!temp_range.end)
return 0;
- /* Split happened */
- if (i == mem->max_nr_ranges - 1)
- return -ENOMEM;
/* Location where new range should go */
j = i + 1;
--
2.42.0
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec