Date: Tue, 26 Apr 2016 11:22:59 -0700 From: NGie Cooper <yaneurabeya@gmail.com> To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= <uspoerlein@gmail.com> Cc: Jamie Gritton <jamie@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail Message-ID: <CA043211-34D4-4562-86A1-F737F8ED1550@gmail.com> In-Reply-To: <CAJ9axoQq6ZY1ys5FVzDFv%2Bpu1JZVaF=eQQ1UNwo9YC_-QKewPg@mail.gmail.com> References: <201604251706.u3PH6okj031018@repo.freebsd.org> <CAJ9axoQq6ZY1ys5FVzDFv%2Bpu1JZVaF=eQQ1UNwo9YC_-QKewPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 26, 2016, at 11:03, Ulrich Sp=C3=B6rlein <uspoerlein@gmail.com> wro= te: >=20 > 2016-04-25 10:06 GMT-07:00 Jamie Gritton <jamie@freebsd.org>: >> Author: jamie >> Date: Mon Apr 25 17:06:50 2016 >> New Revision: 298585 >> URL: https://svnweb.freebsd.org/changeset/base/298585 >>=20 >> Log: >> Encapsulate SYSV IPC objects in jails. Define per-module parameters >> sysvmsg, sysvsem, and sysvshm, with the following bahavior: >>=20 >> 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). >>=20 >> disable: all no access, same as the current setup with allow.sysvipc off= . >>=20 >> 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. >>=20 >> PR: 48471 >> Submitted by: based on work by kikuchan98@gmail.com >> MFC after: 5 days >>=20 >> 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 >=20 > Looks like some bad sbuf_deletes, see the recent Coverity report (are > you folks getting these emails?) >=20 > *** CID 1354974: Memory - corruptions (BAD_FREE) > /sys/kern/sysv_shm.c: 1043 in sysctl_shmsegs() > 1037 shmseg->u.shm_perm.key =3D IPC_PRIVATE; > 1038 } > 1039 > 1040 sbuf_bcat(&sb, shmseg, sizeof(*shmseg)); > 1041 } > 1042 error =3D 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 } >=20 > ** CID 1354975: Memory - corruptions (BAD_FREE) >=20 > and one in sysv_msg.c cem and I hashed this out recently with ntb on phrabricator. The issue is th= at our sbuf implementation is "clever" and has different code paths for stac= k vs heap allocation -- this pattern is ok per stack allocation, but not hea= p allocation... Coverity only knows about how to instrument the latter. Thanks, -Ngie=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA043211-34D4-4562-86A1-F737F8ED1550>