All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Boris Brezillon <bbrezillon@kernel.org>,
	linux-mtd@lists.infradead.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: nand: bbt: clamp GENMASK high bit to word boundary
Date: Mon, 13 Apr 2026 10:12:10 +0200	[thread overview]
Message-ID: <871pgjnusl.fsf@bootlin.com> (raw)
In-Reply-To: <2a62dc1a58f2f8467d95444fa4b37a0af27aeb45.1775951973.git.daniel@makrotopia.org> (Daniel Golle's message of "Sun, 12 Apr 2026 01:05:23 +0100")

Hi Daniel,

On 12/04/2026 at 01:05:23 +01, Daniel Golle <daniel@makrotopia.org> 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èl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Richard Weinberger <richard@nod.at>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 Boris Brezillon <bbrezillon@kernel.org>,
	linux-mtd@lists.infradead.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mtd: nand: bbt: clamp GENMASK high bit to word boundary
Date: Mon, 13 Apr 2026 10:12:10 +0200	[thread overview]
Message-ID: <871pgjnusl.fsf@bootlin.com> (raw)
In-Reply-To: <2a62dc1a58f2f8467d95444fa4b37a0af27aeb45.1775951973.git.daniel@makrotopia.org> (Daniel Golle's message of "Sun, 12 Apr 2026 01:05:23 +0100")

Hi Daniel,

On 12/04/2026 at 01:05:23 +01, Daniel Golle <daniel@makrotopia.org> 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èl

  reply	other threads:[~2026-04-13  8:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-12  0:05 [PATCH] mtd: nand: bbt: clamp GENMASK high bit to word boundary Daniel Golle
2026-04-12  0:05 ` Daniel Golle
2026-04-13  8:12 ` Miquel Raynal [this message]
2026-04-13  8:12   ` Miquel Raynal
2026-04-13 10:57   ` Daniel Golle
2026-04-13 10:57     ` Daniel Golle
2026-04-21  7:32     ` Miquel Raynal
2026-04-21  7:32       ` Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871pgjnusl.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=bbrezillon@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.