On Fri, Mar 12, 2021 at 7:55 AM Ryan Long <[email protected]> wrote:
>
> CID 26033: Dereference after null check in _Objects_Extend_information().
>
> Closes #4326
> ---
> cpukit/score/src/objectextendinformation.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/cpukit/score/src/objectextendinformation.c
> b/cpukit/score/src/objectextendinformation.c
> index 9796eb9..c669301 100644
> --- a/cpukit/score/src/objectextendinformation.c
> +++ b/cpukit/score/src/objectextendinformation.c
> @@ -171,6 +171,17 @@ Objects_Maximum _Objects_Extend_information(
>
> if ( old_maximum > extend_count ) {
> /*
> + * Coverity thinks there is a way for this to be NULL (CID #26033).
> + * After much time spent analyzing this, no one has identified the
> + * conditions where this can actually occur. Adding this _Assert
> ensures
> + * that it is never NULL. If this assert is triggered, condition
> + * generating this case will have been identified and it can be
> revisted.
> + * This is being done out of an abundance of caution since we could
> have
> + * easily flagged this as a false positive and ignored it completely.
> + */
> + _Assert(information->object_blocks != NULL);
> +
That's interesting. It would help if you could share your analysis.
How does
70 if ( information->object_blocks == NULL ) {
be true, and if it is true, how does the exectuion flow proceed in
such a way that it will not reach this assert?
> + /*
> * Copy each section of the table over. This has to be performed as
> * separate parts as size of each block has changed.
> */
> --
> 1.8.3.1
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
