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

Tom Rini
2023-10-25T15:15:41Z

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

On Wed, Oct 25, 2023 at 04:12:37PM +0100, Abdellatif El Khlifi wrote:
> Hi Tom,
>
> > > > ________________________________________________________________________________________________________
> > > > *** CID 464361: Control flow issues (DEADCODE)
> > > > /drivers/firmware/arm-ffa/arm-ffa-uclass.c: 148 in ffa_print_error_log()
> > > > 142
> > > > 143 if (ffa_id < FFA_FIRST_ID || ffa_id > FFA_LAST_ID)
> > > > 144 return -EINVAL;
> > > > 145
> > > > 146 abi_idx = FFA_ID_TO_ERRMAP_ID(ffa_id);
> > > > 147 if (abi_idx < 0 || abi_idx >= FFA_ERRMAP_COUNT)
> > > > >>> CID 464361: Control flow issues (DEADCODE)
> > > > >>> Execution cannot reach this statement: "return -22;".
> > > > 148 return -EINVAL;
> > >
> > > This is a false positive.
> > >
> > > abi_idx value could end up matching this condition "(abi_idx < 0 || abi_idx >= FFA_ERRMAP_COUNT)".
> > >
> > > This happens when ffa_id value is above the allowed bounds. Example: when ffa_id is 0x50 or 0x80
> > >
> > > ffa_print_error_log(0x50, ...); /* exceeding lower bound */
> > > ffa_print_error_log(0x80, ...); /* exceeding upper bound */
> > >
> > > In these cases "return -EINVAL;" is executed.
> >
> > So those invalid values aren't caught by the previous check that ffa_id
> > falls within FFA_FIRST_ID to FFA_LAST_ID ?
>
> I had a closer look at that and I agree that the deadcode defect is legitimate.
> I already provided a fix [1].
>
> [1]: https://lore.kernel.org/all/20231020131533.239591-1-abdellatif.elkhlifi@arm.com/

Ah thanks. I had seen that posted but not put that together with this
email and assumed it was addressing something you hadn't talked about
here because you agreed with it being an issue. I will pick up the
above patch soon then.

--
Tom

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