Re: [PATCH v2 1/2] mtd: rawnand: ingenic: validate BCH error index in jz4725b_correct()

[Paul Cercueil]

Hi,

Le jeudi 05 novembre 2026 à 12:24 +0800, Guanglei Zhu a écrit :
> From: Weibin Liu <liuwb@xxxxxxxxxxxx>
> 
> The JZ4725B BCH controller reports each corrected bit error as an
> index into the codeword it was asked to decode, in the INDEX0/INDEX1
> fields of the BCH_BHERR registers. These fields are 13 bits wide, but
> nothing in jz4725b_correct() checks the reported index against the
> size of the data buffer being corrected:
> 
>     buf[(bit >> 3)] ^= BIT(bit & 0x7);
> 
> With data or ECC coming from an untrusted flash, the decoder can
> report an index that points past the end of the data buffer, and the
> above statement then flips a bit outside the buffer.
> 
> Skip the correction when the reported index does not point into
> the data area.  A bitflip in the parity bytes does not affect the
> data, so rejecting the page for it would fail reads that are
> perfectly correctable, and an index beyond the codeword has no
> buffer to update in the first place.
> 
> Fixes: 3e6ac2ad90b3 ("mtd: rawnand: ingenic: Add support for the JZ4725B")
> Signed-off-by: Weibin Liu <liuwb@xxxxxxxxxxxx>
> ---
> Changes in v2: skip the correction for an index that does not point
> into the data area instead of failing the page with -EBADMSG.  A
> correctable bitflip in the ECC bytes leaves the data valid, and the
> early exit also dropped the error entries that followed it.  This
> matches how jz4740_ecc_correct() treats its indexes.
> 
> Verified with a userspace replica of the correction loop: with
> params->size = 512, an index of 4099 (parity area) followed by a
> data-area index of 100 in the same BHERR register is now corrected
> (v1 returned -EBADMSG and left the data error unfixed), the field
> maximum (0x1fff) produces no write outside the buffer, and in-range
> indexes keep correcting as before.

What bothers me, and maybe it's just me not knowing NAND that well: wouldn't a
bit-flip in the parity area cause a cascade of false-positives in the data too,
leading to BCH_BHINT_UNCOR? Because the ECC code is read from the parity region,
am I wrong?

Cheers,
-Paul