-
Dan Carpenter authored
The problem is that "erasesize" is a uint64_t type so it might be non-zero but the lower 32 bits are zero so when it's truncated, "(uint32_t)erasesize", then that value is zero. This leads to a divide by zero bug. Avoid the bug by delaying the divide until after we have validated that "erasesize" is non-zero and within the uint32_t range. Fixes: dc2b3e5c ("mtd: phram: use div_u64_rem to stop overwrite len in phram_setup") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20220121115505.GI1978@kadam
3e376587