From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 23F95266581 for ; Mon, 13 Apr 2026 08:12:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776067938; cv=none; b=nd1PNRxKbL6hpn8OfXCu5PikiZET4aVghf+Wfm05BRSAfJwjFHx6cONGG5sQjFUkalBJ4+xUzOur/E0QFkNVUwEOUCvvUMgGvu7F4DSB4GVn2FPV25DvwXoZajudiJTkNcVCPyYm+LMc4lqYH+ksiJJ4YjDf+7EZ7KCfmDx1dJM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776067938; c=relaxed/simple; bh=xlQtUgRvCdGzSpIpobD+wGe1i3MkCxAfdWBh+KMd8Xc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mzigDcCZZkw15P5SqUbT62gpCr8YXG87RGyjsmJV5PXE92i1X/SqtP94t8GfMKXc+0esUon4gSYyvB6LrPuqlP5SNrZqhSjHMDIlcxxFIgbfXmkTZqXoY66K7GlR+FSHz0UWvTzFqs1iHXVvIPrvJcNfhZ/muUh2fRzavMq1hBY= 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=lQfk6T5A; arc=none smtp.client-ip=185.246.85.4 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="lQfk6T5A" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id 981324E42951; Mon, 13 Apr 2026 08:12:14 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 674F65FFB9; Mon, 13 Apr 2026 08:12:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 18E8B104501E1; Mon, 13 Apr 2026 10:12:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1776067933; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=xlQtUgRvCdGzSpIpobD+wGe1i3MkCxAfdWBh+KMd8Xc=; b=lQfk6T5AYzgo9MX66zvt/YI5O0ASiMvpjEGLfABg7HNL2Puv2/5MtAnbG0pI7oadppAd1/ nfDCjjV/O7EIc86MEnRUE2y/3B7RC/gUCamg2KW5avqLhDZmIjtGHt+OeOCH5tt4uJMcqg m//FBKvp4mGCSCRmTRM354qm3nzeOCCRkvDYmAMf+VMSkLgrfNDR4tvGipM+/r/MUoFKau K99Imv9+y8gNz3FW/plLPI321ZB9PKuMNeAmAl0mmyJVPR5CAyqaxymbnQ/Uq3mgHj/r/L 3vYMzhV2yYW+Y6LlfKq82Vj9BdMPCozluRlMC6W555mBQiLYlnlyeLrSo+iwmg== 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: <2a62dc1a58f2f8467d95444fa4b37a0af27aeb45.1775951973.git.daniel@makrotopia.org> (Daniel Golle's message of "Sun, 12 Apr 2026 01:05:23 +0100") References: <2a62dc1a58f2f8467d95444fa4b37a0af27aeb45.1775951973.git.daniel@makrotopia.org> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Mon, 13 Apr 2026 10:12:10 +0200 Message-ID: <871pgjnusl.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, On 12/04/2026 at 01:05:23 +01, Daniel Golle wrote: > 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' 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. 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? Thanks, Miqu=C3=A8l