[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MISRA C:2012 D4.11 caution on staging



Hey Julien, please double-check what I am writing below


On Tue, 10 Oct 2023, Nicola Vetrini wrote:
> Hi,
> 
> as you can see from [1], there's a MISRA C guideline, D4.11, that is supposed
> to be clean
> (i.e., have no reports), but has a caution on an argument to memcpy
> (the second argument might be null according to the checker, given a set of
> assumptions on
> the control flow). To access the report just click on the second link in the
> log, which should take you to a webpage with a list of
> MISRA guidelines. Click on D4.11 and you'll see the full report, which I
> pasted below for convenience.
> 
> If the finding is genuine, then some countermeasure needs to be taken against
> this
> possible bug, otherwise it needs to be motivated why the field config->handle
> can't
> be null at that point.
> The finding is likely the result of an improvement made to the checker,
> because the first
> analysis I can see that spots it happened when rc1 has been tagged, but that
> commit does not
> touch the involved files.
> 
> [1] https://gitlab.com/xen-project/xen/-/jobs/5251222578
> 
>  caution for MC3R1.D4.11 untagged
> xen/common/domain.c:758.27-758.40:
> [59] null pointer passed as 2nd argument to memory copy function


This looks like a genuine issue: in domain_create, config->handle could
be uninitialized. For example, domain_create can be called
from xen/arch/arm/domain_build.c:create_domUs, passing &d_cfg, and I
don't see where we initialize d_cfg.handle.

This was just by code inspection. Julien, did I miss anything?



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.