[PATCH 1/2] objectextendinformation.c: Fix Dereference after null check (CID #26033)

[Gedare Bloom]

On Fri, Mar 12, 2021 at 7:55 AM Ryan Long <ryan.long at oarcorp.com> 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
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel