From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (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 11BE4331A78 for ; Tue, 21 Apr 2026 07:32:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776756732; cv=none; b=AkPJtaRyGaGtsFR1Dmurwqqek5KgWZonHxDHMnBbkCN0KfREuA9QFJ8MmYFhBPHHdUJkF+VZzxUtigF6svy3qzAbF9pgLZDfAAffDNG1QmOHELilQ/c1cTyB5FAp2ejhHCNi5me7ev0UcyTzZIYuUWzk9GgamNeVcIv4NSBNo6s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776756732; c=relaxed/simple; bh=3kTU3kTa+ixYcpktW0hrWE8mmmnIo0ZXlgjghpDA6WE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=NBbgBgO4h8kK2ryIlC+0oQfUFSsDIkEwYUtcq5TJ8saaRDTGGkxLtQNCOSfs33wf9K5/9Sj3OMRIDgW2QPokfGx2c98bvLeK3A0HR4IbZjIUdIuGsgAzNbkrx9rlmeNatEukGx2c0OfepjfYaMCivzAg3dUbs/iJOs+t1RqpQ/M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=nWkTs/xr; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="nWkTs/xr" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 1BA281A337C; Tue, 21 Apr 2026 07:32:06 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id DC40E600D2; Tue, 21 Apr 2026 07:32:05 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B3A1110460969; Tue, 21 Apr 2026 09:32:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1776756725; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=3kTU3kTa+ixYcpktW0hrWE8mmmnIo0ZXlgjghpDA6WE=; b=nWkTs/xrJNQIVsHqTPyDs62q/vyf0p8Oo73TuyqxuJy+/8cXRaDP9FUIxeDKy7h4w0S8XA WpInCieYMyb8DD7JevlO6Zw31MbbIOdjSQ420559lapqP0MneEVdyGJBJr1P3ryW1m6M9m kY90751etruk8f807Kcf+00R7tDOOJc1mA5rBrBPBisDFClajN6NLdn0Nohho424DCEvGz Sd6tpmiP9nIAAMhiHMEenAY9Te5yQe38EiXBmlUIK3pdKXMXQsbaBIeSTDDJOmVsLMPGH4 5k9DyllfULEBcpbYgK/eDWK5X6LsnTI4ZPMDZOK6DJ9328lgSoje/sxShM3vmQ== From: Miquel Raynal To: Daniel Golle Cc: Richard Weinberger , Vignesh Raghavendra , Boris Brezillon , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mtd: nand: bbt: clamp GENMASK high bit to word boundary In-Reply-To: (Daniel Golle's message of "Mon, 13 Apr 2026 11:57:02 +0100") References: <2a62dc1a58f2f8467d95444fa4b37a0af27aeb45.1775951973.git.daniel@makrotopia.org> <871pgjnusl.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Tue, 21 Apr 2026 09:32:02 +0200 Message-ID: <87pl3s7or1.fsf@bootlin.com> 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=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 Hi Daniel, >> > When a BBT entry straddles an unsigned long boundary, the GENMASK in >> > nanddev_bbt_set_block_status() can potentially overflow because >> > offs + bits_per_block - 1 can theoretically exceed BITS_PER_LONG - 1. >> > Clamp the high bit so only bits within the current word are masked. >> > The cross-word portion is already handled by the pos[1] block below. >> > >> > Discovered by UBSAN: shift-out-of-bounds in >> > drivers/mtd/nand/bbt.c:116:13 >> > shift exponent 18446744073709551614 is too large for 64-bit type >> > 'long unsigned int' >>=20 >> How likely is that? It doesn't matter how many bits you use per blocks >> (today is 2), it would require a NAND chip that covers an entire country >> to reach that number of blocks. If an attacker plays with that value, >> does it really matter? Apart from writing out of bounds -which is >> physically impossible, we are not talking about virtual memory here- and >> get an error later on, I do not see a good reason for this. >>=20 >> Honestly, I find the final result much less readable than before for no >> obvious added value IMO. But maybe I am looking at this the wrong way? > > It's just the only UBSAN warning I get to see on a recent kernel and my > primary goal here was to make the warning go away. Adding an assertion > to ensure 'offs' is clamped to will likely also make the warning go > away. I believe that's a more appropriate approach, if you don't mind. Thanks, Miqu=C3=A8l