On Tue, Jan 06, 2026 at 10:37:48AM +0100, Mattijs Korpershoek wrote: > Hi Tom, > > On Mon, Jan 05, 2026 at 17:58, Tom Rini <[email protected]> wrote: > > > Hey all, > > > > Here's the latest report, now that next has been merged to master. A few > > of these are oddly showing up now, despite being in older code that > > hasn't been touched and was being built before. > > For fastboot, some code has been moved from mmc only support to > fb_block.c, which might explain the new errors. > > See: > https://lore.kernel.org/all/[email protected]/ > > > > > ---------- Forwarded message --------- > > From: <[email protected]> > > Date: Mon, Jan 5, 2026 at 3:24 PM > > Subject: New Defects reported by Coverity Scan for Das U-Boot > > To: <[email protected]> > > > > > > Hi, > > > > Please find the latest report on new defect(s) introduced to *Das U-Boot* > > found with Coverity Scan. > > > > - *New Defects Found:* 15 > > - 23 defect(s), reported by Coverity Scan earlier, were marked fixed in > > the recent build analyzed by Coverity Scan. > > - *Defects Shown:* Showing 15 of 15 defect(s) > > > > Defect Details > > > > ** CID 640423: Control flow issues (DEADCODE) > > /drivers/fastboot/fb_common.c: 112 in fastboot_set_reboot_flag() > > > > > > _____________________________________________________________________________________________ > > *** CID 640423: Control flow issues (DEADCODE) > > /drivers/fastboot/fb_common.c: 112 in fastboot_set_reboot_flag() > > 106 } > > 107 const char *bcb_iface = > > config_opt_enabled(CONFIG_FASTBOOT_FLASH_BLOCK, > > 108 > > CONFIG_FASTBOOT_FLASH_BLOCK_INTERFACE_NAME, > > 109 "mmc"); > > 110 > > 111 if (device == -1) > >>>> CID 640423: Control flow issues (DEADCODE) > >>>> Execution cannot reach this statement: "return -22;". > > I believe coverity is wrong here. > we call config_opt_enabled() which by default returns -1 so it's > possible to have device == -1 > > This can happen when both CONFIG_FASTBOOT_FLASH_BLOCK and > CONFIG_FASTBOOT_FLASH_MMC are unset. > (for example when we use CONFIG_FASTBOOT_FLASH_SPI) > > > 112 return -EINVAL; > > 113 > > 114 if (reason >= FASTBOOT_REBOOT_REASONS_COUNT) > > 115 return -EINVAL; > > 116 > > 117 ret = bcb_find_partition_and_load(bcb_iface, device, "misc"); > > > > [...] > > > > > ** CID 640421: Possible Control flow issues (DEADCODE) > > /drivers/fastboot/fb_block.c: 138 in > > fastboot_block_get_part_info() > > > > > > _____________________________________________________________________________________________ > > *** CID 640421: Possible Control flow issues (DEADCODE) > > /drivers/fastboot/fb_block.c: 138 in > > fastboot_block_get_part_info() > > 132 > > CONFIG_FASTBOOT_FLASH_BLOCK_DEVICE_ID, -1); > > 133 > > 134 if (!part_name || !strcmp(part_name, "")) { > > 135 fastboot_fail("partition not given", response); > > 136 return -ENOENT; > > 137 } > >>>> CID 640421: Possible Control flow issues (DEADCODE) > >>>> Execution cannot reach the expression "strcmp(interface, "")" inside > >>>> this statement: "if (!interface || !strcmp(i...". > > 138 if (!interface || !strcmp(interface, "")) { > > 139 fastboot_fail("block interface isn't provided", > > response); > > 140 return -EINVAL; > > I believe coverity is wrong here as well. > we call config_opt_enabled() which by default returns NULL for interface. > > And when we enable CONFIG_FASTBOOT_FLASH_BLOCK, > CONFIG_FASTBOOT_FLASH_BLOCK_INTERFACE_NAME will be set to "" by default: > > $ rg 'FASTBOOT_FLASH_BLOCK_INTERFACE_NAME' .config > 1097:CONFIG_FASTBOOT_FLASH_BLOCK_INTERFACE_NAME="" > > > > 141 } > > 142 > > 143 *dev_desc = blk_get_dev(interface, device); > > > > [...] > > > > > ** CID 640419: Null pointer dereferences (REVERSE_INULL) > > /drivers/fastboot/fb_block.c: 144 in > > fastboot_block_get_part_info() > > > > > > _____________________________________________________________________________________________ > > *** CID 640419: Null pointer dereferences (REVERSE_INULL) > > /drivers/fastboot/fb_block.c: 144 in > > fastboot_block_get_part_info() > > 138 if (!interface || !strcmp(interface, "")) { > > 139 fastboot_fail("block interface isn't provided", > > response); > > 140 return -EINVAL; > > 141 } > > 142 > > 143 *dev_desc = blk_get_dev(interface, device); > >>>> CID 640419: Null pointer dereferences (REVERSE_INULL) > >>>> Null-checking "dev_desc" suggests that it may be null, but it has > >>>> already been dereferenced on all paths leading to the check. > > 144 if (!dev_desc) { > > 145 fastboot_fail("no such device", response); > > 146 return -ENODEV; > > 147 } > > Fair enough for this one. We can check that dev_desc is not NULL to make > sure that the caller cannot call fastboot_block_get_part_info() with > NULL as second argument. > > I'll submit a patch for this once I've cleared out my review queue. > > > 148 > > 149 ret = part_get_info_by_name(*dev_desc, part_name, part_info); > > > > > > [...] > > For the first 2, do you want me to update the coverity database online > with these explanations? > It has been a while but I think I can do that myself.
Thanks for looking in to all of these. I've gone ahead and updated Coverity, but in the future if you'd like to go in and do that while composing the emails, please feel free. -- Tom
signature.asc
Description: PGP signature
