Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Signed integer overflow in size calculation in kho_preserved_memory_reserve(). -- commit 64e1a8a692077719d0e7f42a7ff19088fba754f4 Author: Pratyush Yadav (Google) <[email protected]> kho: add data argument to radix walk callback This commit adds an opaque data pointer argument to kho_radix_walk_cb_t. This allows callers to pass extra information to the callback functions during tree walks. > diff --git a/kernel/liveupdate/kexec_handover.c > b/kernel/liveupdate/kexec_handover.c > index 0f8d058f1a272..f6de6bf632261 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c [ ... ] > @@ -486,7 +488,7 @@ static struct page *__init > kho_get_preserved_page(phys_addr_t phys, > return pfn_to_page(pfn); > } > > -static int __init kho_preserved_memory_reserve(unsigned long key) > +static int __init kho_preserved_memory_reserve(unsigned long key, void *data) > { > union kho_page_info info; > struct page *page; [Severity: High] This isn't a bug introduced by this patch, but does sz overflow when calculating the memory size in this function? Looking at kho_preserved_memory_reserve(), the memory size is calculated as: sz = 1 << (order + PAGE_SHIFT); The literal 1 is a signed 32-bit integer. When KHO preserves memory using kho_preserve_pages(), the maximum order is bounded by NUMA node boundaries rather than MAX_PAGE_ORDER, allowing very large contiguous chunks to be preserved as a single radix tree entry. For example, if a 2GB contiguous memory chunk is preserved, the order is 19. With PAGE_SHIFT = 12, order + PAGE_SHIFT is 31. The expression 1 << 31 overflows the signed 32-bit integer into -2147483648, which is then sign-extended into u64 sz as 0xffffffff80000000. If order + PAGE_SHIFT >= 32 (e.g., preserving a 4GB chunk), the behavior is undefined and often evaluates to 1. Calling memblock_reserve() with either of these invalid sizes will cause the system to either exhaust all physical memory and fail to boot, or fail to actually reserve the preserved memory, leading to severe memory corruption when the successor kernel allocates and overwrites the preserved state. Could this expression be updated to use the 1ULL literal to prevent overflow? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
