linux-kernel - Re: [PATCH] mtd: nand: ecc-mxic: Fix use of uninitialized variable ret

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87v7rdhjiu.fsf@bootlin.com>
Date: Wed, 09 Apr 2025 09:38:17 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Mikhail Arkhipov <m.arhipov@...a.ru>
Cc: Richard Weinberger <richard@....at>,  Vignesh Raghavendra
 <vigneshr@...com>,  linux-mtd@...ts.infradead.org,
  linux-kernel@...r.kernel.org,  lvc-project@...uxtesting.org
Subject: Re: [PATCH] mtd: nand: ecc-mxic: Fix use of uninitialized variable ret

On 09/04/2025 at 00:39:06 +03, Mikhail Arkhipov <m.arhipov@...a.ru> wrote:

> If ctx->steps is zero, the loop processing ECC steps is skipped,
> and the variable ret remains uninitialized. It is later checked
> and returned, which leads to undefined behavior and may cause
> unpredictable results in user space or kernel crashes.
>
> This scenario can be triggered in edge cases such as misconfigured
> geometry,

Would clearly be a huge bug, nothing else would work in this case, not a
single read, ie. we would stop way before reaching this point.

> ECC engine misuse,

Ditto.

> or if ctx->steps is not validated after initialization.

steps = mtd->writesize / 1K
and
we only run on large-page NANDs, ie. chips with mtd->writesize >= 1K.
so this case is not plausible.

> Initialize ret to zero before the loop to ensure correct and safe
> behavior regardless of the ctx->steps value.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: 48e6633a9fa2 ("mtd: nand: mxic-ecc: Add Macronix external ECC
> engine support")

I will apply, but honestly I do not think this fixes anything.

> Signed-off-by: Mikhail Arkhipov <m.arhipov@...a.ru>

Thanks,
Miquèl