svn commit: r298585 - in head: sys/kern usr.sbin/jail

Conrad Meyer cem at FreeBSD.org
Tue Apr 26 18:44:44 UTC 2016


Right.  False positive.  Coverity doesn't grok sbuf memory management fully.

On Tue, Apr 26, 2016 at 11:22 AM, NGie Cooper <yaneurabeya at gmail.com> wrote:

>
> > On Apr 26, 2016, at 11:03, Ulrich Spörlein <uspoerlein at gmail.com> wrote:
> >
> > 2016-04-25 10:06 GMT-07:00 Jamie Gritton <jamie at freebsd.org>:
> >> Author: jamie
> >> Date: Mon Apr 25 17:06:50 2016
> >> New Revision: 298585
> >> URL: https://svnweb.freebsd.org/changeset/base/298585
> >>
> >> Log:
> >>  Encapsulate SYSV IPC objects in jails.  Define per-module parameters
> >>  sysvmsg, sysvsem, and sysvshm, with the following bahavior:
> >>
> >>  inherit: allow full access to the IPC primitives.  This is the same as
> >>  the current setup with allow.sysvipc is on.  Jails and the base system
> >>  can see (and moduly) each other's objects, which is generally
> considered
> >>  a bad thing (though may be useful in some circumstances).
> >>
> >>  disable: all no access, same as the current setup with allow.sysvipc
> off.
> >>
> >>  new: A jail may see use the IPC objects that it has created.  It also
> >>  gets its own IPC key namespace, so different jails may have their own
> >>  objects using the same key value.  The parent jail (or base system) can
> >>  see the jail's IPC objects, but not its keys.
> >>
> >>  PR:           48471
> >>  Submitted by: based on work by kikuchan98 at gmail.com
> >>  MFC after:    5 days
> >>
> >> Modified:
> >>  head/sys/kern/sysv_msg.c
> >>  head/sys/kern/sysv_sem.c
> >>  head/sys/kern/sysv_shm.c
> >>  head/usr.sbin/jail/jail.8
> >
> > Looks like some bad sbuf_deletes, see the recent Coverity report (are
> > you folks getting these emails?)
> >
> > *** CID 1354974:  Memory - corruptions  (BAD_FREE)
> > /sys/kern/sysv_shm.c: 1043 in sysctl_shmsegs()
> > 1037                            shmseg->u.shm_perm.key = IPC_PRIVATE;
> > 1038                    }
> > 1039
> > 1040                    sbuf_bcat(&sb, shmseg, sizeof(*shmseg));
> > 1041            }
> > 1042            error = sbuf_finish(&sb);
> >>>>    CID 1354974:  Memory - corruptions  (BAD_FREE)
> >>>>    "sbuf_delete" frees address of "sb".
> > 1043            sbuf_delete(&sb);
> > 1044
> > 1045     done:
> > 1046            SYSVSHM_UNLOCK();
> > 1047            return (error);
> > 1048     }
> >
> > ** CID 1354975:  Memory - corruptions  (BAD_FREE)
> >
> > and one in sysv_msg.c
>
> cem and I hashed this out recently with ntb on phrabricator. The issue is
> that our sbuf implementation is "clever" and has different code paths for
> stack vs heap allocation -- this pattern is ok per stack allocation, but
> not heap allocation... Coverity only knows about how to instrument the
> latter.
>
> Thanks,
> -Ngie
>


More information about the svn-src-all mailing list