Fwd: New Defects reported by Coverity Scan for Das U-Boot
    Tom Rini 
    trini at konsulko.com
       
    Sun Oct 12 21:07:13 CEST 2025
    
    
  
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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251012/f3aaf581/attachment.sig>
    
    
More information about the U-Boot
mailing list