[PATCH v2 0/2] mtd: rawnand: vf610_nfc: fix reads on chips with more than 64 bytes of OOB

[Mehmet Fide]

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