From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (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 BB4CE2E7380 for ; Thu, 18 Jun 2026 18:58:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781809095; cv=none; b=aUfSEbiJG4fi7DGxRMEimNxRI+RJD+IMz8mCAaNiUpzJqkLMJgVRCPDzJhkGFNmTLyjj3O91mb9+pYO+4OfFHhVcnlhuwLRndkR8/sahaEVtMg3oyu9Wwl6pIdqEo9Upr6Q41nssBpW49d2xlu3sNMfB8el9Gk09yIrIn0hEleo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781809095; c=relaxed/simple; bh=PD6CHh12XmvOzKqEhPnlPddPvwTRfUqT40UI+Wz7KZU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pBxqlS9TwY6T+jJWIkHgNRxnPCi3RNJdORiHj2XO/POTSu4LDHzQpcv+pYP0bhgUMokPC8LhshnNNRpjKJELrrEDTNKa+YDYVIuobR3krMsKQG0KZTSw1UpwjmemsgOyJGpk/p0ojCHTMhkreJJ91zPT0h87sQjyOz35c4YfPzE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=lNzC74sl; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="lNzC74sl" Date: Thu, 18 Jun 2026 20:57:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781809081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ccRwH1M9+EU8H0Zn/3IoMPQP/R82XHic9JmeEjLVWNs=; b=lNzC74slItOJob95QVJFnMjXkZVw079r7zo+HtHEUoBGMFNu3qGyeWDFeC9Ko3JHGMcw+d OlKXj2G1TRswuGsSFEoDq2kDElQD1kLIH+wp0nwkmc+AulZhYozRgV9zXvK+mFMpcPHM1p R3odZB//Mnqlw0CbJN7clptVx4NN3cQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Thorsten Blum To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Chao Fan , stable@vger.kernel.org, Borislav Petkov , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/boot: Reject truncated acpi_rsdp= values Message-ID: References: <20260617130417.36651-4-thorsten.blum@linux.dev> <20260618045400.GCajN56AKctO0qB-sF@fat_crate.local> <20260618163856.GAajQfIDh0s31VINiS@fat_crate.local> <20260618180412.GBajQzHB3Rj0SrS1Eo@fat_crate.local> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260618180412.GBajQzHB3Rj0SrS1Eo@fat_crate.local> X-Migadu-Flow: FLOW_OUT On Thu, Jun 18, 2026 at 11:04:12AM -0700, Borislav Petkov wrote: > On Thu, Jun 18, 2026 at 07:59:09PM +0200, Thorsten Blum wrote: > > On Thu, Jun 18, 2026 at 09:38:56AM -0700, Borislav Petkov wrote: > > > On Thu, Jun 18, 2026 at 05:03:46PM +0200, Thorsten Blum wrote: > > > > get_cmdline_acpi_rsdp() can truncate it into a different, parseable > > > > address and use that instead. > > > > > > How? > > > > The buffer has 19 bytes to hold the "0x" prefix, 16 hex digits, and the > > NUL terminator. > > > > cmdline_find_option() copies only bufsize - 1 bytes, but returns the > > full argument length. So for example: > > > > acpi_rsdp=0x0123456789abcdefx > > > > gets copied as: > > > > 0x0123456789abcdef > > > > which boot_kstrtoul() parses successfully. The user supplied an invalid > > value, but we silently use the truncated prefix as the RSDP address. > > My question stands: > > "Or are we protecting people from shooting themselves in foot now too?" > > Especially users who should know what they're doing... > > IOW, how far are we going to "protect" here? Only far enough to avoid using a value the user didn't actually enter. A user can still shoot themselves in the foot by using a syntactically valid but wrong address. The check only rejects an overlong acpi_rsdp= value after cmdline_find_option() reports that it didn't fit in the buffer. We already reject values that boot_kstrtoul() fails to parse; this is the same idea: the copied string is incomplete and shouldn't be parsed. Thanks, Thorsten