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

Mikhail Kshevetskiy
2025-11-01T06:32:45Z

Hello Tom,

I just sent a fix for the issue in the my "coverity and 64-bit division
fixes" series.
If it's needed I can split the series and send patches separately.

Regards,
Mikhail Kshevetskiy

On 10/12/25 22:07, Tom Rini wrote:
> 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.
>