Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot

Tom Rini
2025-10-12T19:07:22Z

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

On Sun, Oct 12, 2025 at 05:22:15PM +0300, Mikhail Kshevetskiy wrote:
>
> On 11.10.2025 21:06, Tom Rini wrote:
> > I think unfortunately the report email for when I merged in -next was
> > lost somewhere / wasn't sent. I may be able to get the details out the
> > dashboard.
> >
> > ---------- Forwarded message ---------
> > From: <scan-admin@coverity.com>
> > Date: Fri, Oct 10, 2025 at 7:08 PM
> > Subject: New Defects reported by Coverity Scan for Das U-Boot
> > To: <tom.rini@gmail.com>
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to *Das U-Boot*
> > found with Coverity Scan.
> >
> > - *New Defects Found:* 1
> > - *Defects Shown:* Showing 1 of 1 defect(s)
> >
> > Defect Details
> >
> > ** CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
> > /drivers/spi/spi-mem.c: 528 in spi_mem_calc_op_duration()
> >
> >
> > _____________________________________________________________________________________________
> > *** CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
> > /drivers/spi/spi-mem.c: 528 in spi_mem_calc_op_duration()
> > 522 ncycles += ((op->addr.nbytes * 8) / op->addr.buswidth) /
> > (op->addr.dtr ? 2 : 1);
> > 523
> > 524 /* Dummy bytes are optional for some SPI flash memory operations */
> > 525 if (op->dummy.nbytes)
> > 526 ncycles += ((op->dummy.nbytes * 8) / op->dummy.buswidth) /
> > (op->dummy.dtr ? 2 : 1);
> > 527
> >>>> CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN)
> >>>> Potentially overflowing expression "op->data.nbytes * 8U" with type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, and then used in a context that expects an expression of type "u64" (64 bits, unsigned).
> > 528 ncycles += ((op->data.nbytes * 8) / op->data.buswidth) /
> > (op->data.dtr ? 2 : 1);
>
>
> op->data.nbytes  comes from file drivers/mtd/nand/spi/core.c, function
> spinand_select_op_variant().
> According to the code the max value of op->data.nbytes is
>
>         nanddev_per_page_oobsize(nand) + nanddev_page_size(nand)
>
> thus it's slightly more than 4Kb (I never seen flashes with page size
> large than 4Kb). According to this estimation the overflow will never
> happen.
>
> If it make sense, I can try to do something with it

Yes, please see what you can do about it and thanks for explaining that
it shouldn't be an actual problem.

--
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]