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