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 CE4C813B280; Wed, 3 Jul 2024 11:27:22 +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=1720006042; cv=none; b=jmnzc8PWjp6eGqLvzP1de/xmJt3BuydcWkFdWQ5jXVyHBqriHfRey9OGvt0igv2SYGZ+CWFCOrmQd89gFq/VvSWUgf3ydF0BjcxAkNlcLOwO3ht9gvPfy73Ugucpuqqmh5Owmwi3YUg3X7d6SYn9VgZ2EpeHI1cgk3+M5W1wj9w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720006042; c=relaxed/simple; bh=G8tQI3Vs6PKKe+N7II8qczfimkJOX3OkBebEFFygN4o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Z08+ynfQD9kyZMpCYEE5A4F/z9+q9rO9ijiCU4QdzBwLllYxzT+hk/kzkmpHWyhnmBm6N31v89kRyPfYYVNn+yE6yYTRLXKfOkhIc2Eccs8KcMdZog5egGIkVZLTDhBzJ48dX4yO5Fj3RWM+2Xnnf+UgqegS123Uq37QX03zNZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=FRMOw6Gm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="FRMOw6Gm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 520CFC2BD10; Wed, 3 Jul 2024 11:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1720006042; bh=G8tQI3Vs6PKKe+N7II8qczfimkJOX3OkBebEFFygN4o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FRMOw6Gm3Hm+Q1O06tBKjVVMt0KG6u/XsuQsB9udK2SnAIk5woICDXHoIcrBsTODr 2gekf7cEebYDnCH6nWKQzWX5Jj+xSDlr98+mHcNDc16cEtGnqX+K0/b7BaxytnEB7f gXXlgVdAHRjJo3A308sx0iVgOhYn8vI2ujsJLTxQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, =?UTF-8?q?Bj=C3=B6rn=20T=C3=B6pel?= , Nam Cao , =?UTF-8?q?Bj=C3=B6rn=20T=C3=B6pel?= , "Mike Rapoport (IBM)" , Palmer Dabbelt , Sasha Levin Subject: [PATCH 5.15 250/356] riscv: fix overlap of allocated page and PTR_ERR Date: Wed, 3 Jul 2024 12:39:46 +0200 Message-ID: <20240703102922.577139484@linuxfoundation.org> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240703102913.093882413@linuxfoundation.org> References: <20240703102913.093882413@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Nam Cao [ Upstream commit 994af1825a2aa286f4903ff64a1c7378b52defe6 ] On riscv32, it is possible for the last page in virtual address space (0xfffff000) to be allocated. This page overlaps with PTR_ERR, so that shouldn't happen. There is already some code to ensure memblock won't allocate the last page. However, buddy allocator is left unchecked. Fix this by reserving physical memory that would be mapped at virtual addresses greater than 0xfffff000. Reported-by: Björn Töpel Closes: https://lore.kernel.org/linux-riscv/878r1ibpdn.fsf@all.your.base.are.belong.to.us Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code") Signed-off-by: Nam Cao Cc: Tested-by: Björn Töpel Reviewed-by: Björn Töpel Reviewed-by: Mike Rapoport (IBM) Link: https://lore.kernel.org/r/20240425115201.3044202-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin --- arch/riscv/mm/init.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index c9d63c476d315..c30cc3ac93a72 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -192,18 +192,19 @@ static void __init setup_bootmem(void) phys_ram_base = memblock_start_of_DRAM(); #endif /* - * memblock allocator is not aware of the fact that last 4K bytes of - * the addressable memory can not be mapped because of IS_ERR_VALUE - * macro. Make sure that last 4k bytes are not usable by memblock - * if end of dram is equal to maximum addressable memory. For 64-bit - * kernel, this problem can't happen here as the end of the virtual - * address space is occupied by the kernel mapping then this check must - * be done as soon as the kernel mapping base address is determined. + * Reserve physical address space that would be mapped to virtual + * addresses greater than (void *)(-PAGE_SIZE) because: + * - This memory would overlap with ERR_PTR + * - This memory belongs to high memory, which is not supported + * + * This is not applicable to 64-bit kernel, because virtual addresses + * after (void *)(-PAGE_SIZE) are not linearly mapped: they are + * occupied by kernel mapping. Also it is unrealistic for high memory + * to exist on 64-bit platforms. */ if (!IS_ENABLED(CONFIG_64BIT)) { - max_mapped_addr = __pa(~(ulong)0); - if (max_mapped_addr == (phys_ram_end - 1)) - memblock_set_current_limit(max_mapped_addr - 4096); + max_mapped_addr = __va_to_pa_nodebug(-PAGE_SIZE); + memblock_reserve(max_mapped_addr, (phys_addr_t)-max_mapped_addr); } min_low_pfn = PFN_UP(phys_ram_base); -- 2.43.0