From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 622BD383C6C for ; Fri, 20 Mar 2026 09:34:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773999249; cv=none; b=oxeLW5PVwgsocMvl78xI4rWwB+MS543jQXuG9J8FjEOakrxhgDmHNR2gbJmRktYBRt5Oxl6dqzp9OxiKTTjj7rMjBuyG8nIQJfHDH1vH7mOHwXgjJm1S9cHS5GloJtzaTDyBkNeo4tNvXYerY+w+Mw2Gz5LUNCxeJ4DKHPYofjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773999249; c=relaxed/simple; bh=1pObmRVkfeuQHYXDX4q0M1f+DzcmBEqslPtmpLMlMHI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hLD0+CvT25uPuPVfFmEYwljwnnp453CRYITSK33w+l+/ueLU/6sC5iyrqILZj1pN2+qn5dgFPc/HExFUZY0ebAYVIhiAMcUKDPMzKTVveBLtr8WzJbSQ796Z5kmTzqdP1fCRXVlkuqiCacMdAxQPAS2H3avIOTbMFOG1Iv4nEdc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LRIN//CB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LRIN//CB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8171C4CEF7; Fri, 20 Mar 2026 09:34:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773999248; bh=1pObmRVkfeuQHYXDX4q0M1f+DzcmBEqslPtmpLMlMHI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LRIN//CB6MP+nL28Urhsf35RBU+5j+q4s9WMUnkan6oPM5eUelTBgsLXNwnb6cj+7 /wlQgCFQ9QStiUsV3QXxDxCPt6K7Po24n9hJt+xABILmFuebTJmAZtPeDVD3leehRi ZbNbYFJqQ55b38pAAVD9HJgWK1inJ2m0xriETxGH95kCunDnLqEEeDSpRrB1pYkoxs XK8P1rnwPgyQ/LanSiCVzqhHTWiC+JY5kGush4hpuqJHL4xxIsuXb1o0hXcZelek9w NyUXdLYDUopFe6DYKiCYqH3GsIPy6V9K6fsRotl612dRlmadMWmv3Jk3hCn7hSLY8b q9Fb92lDd2bhw== From: Pratyush Yadav To: Andrew Morton Cc: Marco Elver , Alexander Graf , Mike Rapoport , Pasha Tatashin , Pratyush Yadav , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com Subject: Re: [PATCH v2] kho: use checked arithmetic in deserialize_bitmap() In-Reply-To: <20260319193735.2ea34594b36d37e7850a8c37@linux-foundation.org> (Andrew Morton's message of "Thu, 19 Mar 2026 19:37:35 -0700") References: <20260319210528.1694513-2-elver@google.com> <20260319193735.2ea34594b36d37e7850a8c37@linux-foundation.org> Date: Fri, 20 Mar 2026 09:34:05 +0000 Message-ID: <2vxzv7eqc0aa.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Thu, Mar 19 2026, Andrew Morton wrote: > On Thu, 19 Mar 2026 22:03:53 +0100 Marco Elver 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