The expression '1 << EraseUnitSize' is evaluated in int, which causes
a negative result when shifting by 31 - the upper bound of the valid
range [10, 31], enforced by scan_header(). This leads to incorrect
extension when storing the result in 'erase->len' (uint64_t), producing
a large unexpected value.

Found by Linux Verification Center (linuxtesting.org) with Svace.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Ivan Stepchenko <sid@itb.spb.ru>
---
 drivers/mtd/ftl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/ftl.c b/drivers/mtd/ftl.c
index 8c22064ead38..f2bd1984609c 100644
--- a/drivers/mtd/ftl.c
+++ b/drivers/mtd/ftl.c
@@ -344,7 +344,7 @@ static int erase_xfer(partition_t *part,
             return -ENOMEM;
 
     erase->addr = xfer->Offset;
-    erase->len = 1 << part->header.EraseUnitSize;
+    erase->len = 1ULL << part->header.EraseUnitSize;
 
     ret = mtd_erase(part->mbd.mtd, erase);
     if (!ret) {
-- 
2.39.5

On Thu, 19 Jun 2025 17:53:13 +0300, Ivan Stepchenko wrote:
> The expression '1 << EraseUnitSize' is evaluated in int, which causes
> a negative result when shifting by 31 - the upper bound of the valid
> range [10, 31], enforced by scan_header(). This leads to incorrect
> extension when storing the result in 'erase->len' (uint64_t), producing
> a large unexpected value.
> 
> Found by Linux Verification Center (linuxtesting.org) with Svace.
> 
> [...]

Applied to mtd/next, thanks!

[1/1] mtd: fix possible integer overflow in erase_xfer()
      commit: 9358bdb9f9f54d94ceafc650deffefd737d19fdd

Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).

Kind regards,
Miquèl