From: Mehmet Fide <mehmet.fide@screeningeagle.com>

The driver only implements the 64-byte OOB format the controller
transfers, so chips with a larger OOB (the Colibri VF61's MX30LF4G28AC
has 112 bytes) stopped working when nanddev_init() began restoring
mtd->oobsize after ->attach_chip(): the parity moved and every
ECC-protected read failed, including the BBT and everything UBI needs.

v2 takes the approach Miquel suggested instead of clamping the memory
organization: the detected OOB size stays, the driver gets its own
mtd_ooblayout_ops computed on the first 64 OOB bytes, and the data
paths keep transferring exactly those 64 spare bytes, so the on-flash
format stays identical to U-Boot and to the kernels that clamped.

Tested on a Colibri VF61 (112-byte OOB): mtd->oobsize now reads 112,
the flash-based BBT is found and read without errors, UBIFS written by
a clamping kernel mounts read-write, and an 8 MiB write/read-back
returns identical data with zero corrected bits. Regression-tested on a
Colibri VF50 (64-byte OOB chip): unchanged layout, oobavail and clean
ECC counters.

The two pre-existing issues the Sashiko report flagged on v1 are sent
as a separate series, as they are independent of this fix.

v1: https://lore.kernel.org/linux-mtd/20260818114208.2780311-1-mehmet.fide@gmail.com/


Mehmet Fide (2):
  mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of
    OOB
  mtd: rawnand: vf610_nfc: fix false bitflips on reads of erased pages

 drivers/mtd/nand/raw/vf610_nfc.c | 66 ++++++++++++++++++++++++++------
 1 file changed, 55 insertions(+), 11 deletions(-)

-- 
2.54.0

On 28/08/2026 at 10:53:35 +02, Mehmet Fide <mehmet.fide@gmail.com> wrote:

> From: Mehmet Fide <mehmet.fide@screeningeagle.com>

Sashiko says:

> New issues:
> - [High] Kernel heap memory is leaked to userspace during out-of-band
> (OOB) reads when the NAND chip's OOB size is larger than 64 bytes.

Probably right, to be checked.

> - [Medium] Integer underflows occur in OOB layout functions when the
> flash chip's spare size is smaller than the required ECC bytes + 2,
> leading to an inflated `mtd->oobavail` and potential heap buffer
> overflow.

Cannot happen.

> Pre-existing issues:
> - [High] `vf610_nfc_write_page()` completely ignores the `oob_required`
> parameter and fails to copy the caller's OOB data into the controller's
> SRAM, leading to stale data written to the flash.

Probably true.

Cheers,
Miquèl

Hi Miquel,

> Sashiko says:
>
> > New issues:
> > - [High] Kernel heap memory is leaked to userspace during out-of-band
> > (OOB) reads when the NAND chip's OOB size is larger than 64 bytes.
>
> Probably right, to be checked.

Checked, and Sashiko is right. vf610_nfc_read_page() fills only the
first 64 bytes of oob_poi while the core is free to copy the full
mtd->oobsize from it on an MTD_OPS_PLACE_OOB read, so the remaining
bytes expose whatever the buffer held before. The raw paths are fine,
they bypass the engine and transfer the chip's real spare area. v3 will
fill the tail of oob_poi with 0xff after the copy, which also matches
what raw reads see on flash, since the write path only ever programs
the first 64 spare bytes.

> > - [Medium] Integer underflows occur in OOB layout functions when the
> > flash chip's spare size is smaller than the required ECC bytes + 2,
> > leading to an inflated `mtd->oobavail` and potential heap buffer
> > overflow.
>
> Cannot happen.

Agreed: the layout is only installed in the hwecc path, where
attach_chip() rejects chips with less than 64 bytes of OOB, and the
largest ECC mode uses 60 bytes + 2, which still fits.

> > Pre-existing issues:
> > - [High] `vf610_nfc_write_page()` completely ignores the `oob_required`
> > parameter and fails to copy the caller's OOB data into the controller's
> > SRAM, leading to stale data written to the flash.
>
> Probably true.

It is true, and it is exactly what the first patch of the other series
I posted the same day fixes:

https://lore.kernel.org/linux-mtd/20260828085340.3916239-2-mehmet.fide@gmail.com/

One correction to that series' cover letter while we are here: it calls
the two fixes independent of this one, but its first patch uses the
vf610_nfc_spare_size() helper this series introduces, so it only builds
on top of it. Apply order is this series first.

Thanks,
Mehmet