Re: [PATCH v2] kho: use checked arithmetic in deserialize_bitmap()

[Pratyush Yadav <pratyush@kernel.org>]

On Thu, Mar 19 2026, Andrew Morton wrote:

> On Thu, 19 Mar 2026 22:03:53 +0100 Marco Elver <elver@google.com> wrote:
>
>> The function deserialize_bitmap() calculates the reservation size using:
>> 
>>     int sz = 1 << (order + PAGE_SHIFT);
>> 
>> If a corrupted KHO image provides an order >= 20 (on systems with 4KB
>> pages), the shift amount becomes >= 32, which overflows the 32-bit
>> integer. This results in a zero-size memory reservation.
>> 
>> Furthermore, the physical address calculation:
>> 
>>     phys_addr_t phys = elm->phys_start + (bit << (order + PAGE_SHIFT));
>> 
>> can also overflow and wrap around if the order is large. This allows a
>> corrupt KHO image to cause out-of-bounds updates to page->private of
>> arbitrary physical pages during early boot.
>> 
>> Fix this by changing 'sz' to 'unsigned long' and using checked add and
>> shift to safely calculate the shift amount, size, and physical address,
>> skipping malformed chunks. This allows preserving memory with an order
>> larger than MAX_PAGE_ORDER.
>
> AI review asked questions:
> 	https://sashiko.dev/#/patchset/20260319210528.1694513-2-elver%40google.com

I have also been keeping an eye sashiko for kho/live update patches. I
think it is missing some context for KHO/live update, like the fact that
only 64-bit platforms are supported, FDT data doesn't need to care for
endianness, and so on. I think we need a set of subsystem prompts for
KHO and live update. I am experimenting around with a local deployment
of sashiko. I'll see if I can get a basic set of prompts working.

The the LLM review of this patch, I think the only relevant comment is
checking if elm->bitmap is NULL.

For the others:

1. The restore path does (should) support order larger than
   MAX_PAGE_ORDER. I sent this series [0] to make that work properly.
2. KHO is not supported on 32-bit.
3. We just have to trust the previous kernel. There is no sane way of
   preventing attacks if the previous kernel is malicious. For example,
   it might as well give us valid memory addresses, but change the
   contents there. So all of these checks only defend against buggy
   kernels, not against malicious ones.

[0] https://lore.kernel.org/linux-mm/20260309123410.382308-1-pratyush@kernel.org/T/#u

-- 
Regards,
Pratyush Yadav