New Defects reported by Coverity Scan for RTEMS

[Kinsey Moore]

On Wed, Mar 22, 2023 at 4:00 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Mon, Mar 20, 2023 at 6:56 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> > New issue from Coveriry.
> >
> > I vaguely recall that JFFS2 uses dynamic checks for things that static
> would work and Coveriry spots the dead code
> >
> > ---------- Forwarded message ---------
> > From: <scan-admin at coverity.com>
> > Date: Sun, Mar 19, 2023, 10:59 PM
> > Subject: New Defects reported by Coverity Scan for RTEMS
> > To: <build at rtems.org>
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to RTEMS found
> with Coverity Scan.
> >
> > 4 new defect(s) introduced to RTEMS found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 4 of 4 defect(s)
> >
> >
> > ** CID 1523448:  Control flow issues  (DEADCODE)
> > /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()
> >
> >
> >
> ________________________________________________________________________________________________________
> > *** CID 1523448:  Control flow issues  (DEADCODE)
> > /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()
> > 131             struct jffs2_raw_node_ref *raw;
> > 132             uint32_t gcblock_dirty;
> > 133             int ret = 0, inum, nlink;
> > 134             int xattr = 0;
> > 135
> > 136             if (mutex_lock_interruptible(&c->alloc_sem))
> > >>>     CID 1523448:  Control flow issues  (DEADCODE)
> > >>>     Execution cannot reach this statement: "return -4;".
> > 137                     return -EINTR;
> > 138
> > 139
> > 140             for (;;) {
> > 141                     /* We can't start doing GC until we've finished
> checking
> > 142                        the node CRCs etc. */
> >
>
> This is a bug. It can be fixed by removing the error handling, because
> mutex_lock_interruptible has no return value.
>
> > ** CID 1523447:  Null pointer dereferences  (FORWARD_NULL)
> > /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()
> >
> >
> >
> ________________________________________________________________________________________________________
> > *** CID 1523447:  Null pointer dereferences  (FORWARD_NULL)
> > /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()
> > 1364            } else {
> > 1365                    err = -ENOMEM;
> > 1366            }
> > 1367
> > 1368            sb = &fs_info->sb;
> > 1369            c = JFFS2_SB_INFO(sb);
> > >>>     CID 1523447:  Null pointer dereferences  (FORWARD_NULL)
> > >>>     Dereferencing null pointer "c".
> > 1370            c->mtd = NULL;
> > 1371
> > 1372            if (err == 0) {
> > 1373                    rtems_recursive_mutex_init(&sb->s_mutex,
> RTEMS_FILESYSTEM_TYPE_JFFS2);
> > 1374            }
> > 1375
> >
> This is a bug, because c == &sb->jffs2_info == &fs_info->sb ==
> fs_info. Protect this dereference with `if (err == 0)`. I think the
> sequence of code starting with `sb = ...` can be moved into the `if`
> block at line 1372.
>

This one is my fault and is in RTEMS-owned code. Patch incoming to fix it.

The rest are in JFFS2-owned code and are either false positives or are
flagged due to the #define implementation of mutex_lock_interruptible
always returning 0.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230322/894feab5/attachment.htm>