From owner-svn-src-head@freebsd.org Tue Apr 26 18:44:44 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3DC3B1C808; Tue, 26 Apr 2016 18:44:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-oi0-f67.google.com (mail-oi0-f67.google.com [209.85.218.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1A2B1A80; Tue, 26 Apr 2016 18:44:44 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-oi0-f67.google.com with SMTP id i2so3211718oib.3; Tue, 26 Apr 2016 11:44:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=XCqDzRsHpzuv+yPaVOGjiRfjJYYXIrRHDVdhEjJMk3Q=; b=CzeewQRaOATtzXIGBJRLlY6IEuTkcO9mvtJqBFjwlha1Jaox46GX7Ey37EMPydx1un r9/wcnXPIHPjnQI65yvLROX5ca58+pHuF4Z6FF0tHDXlqj50Z3pCIoTBUxHfX0HafO1C +L9FGIQuDuLY7JUkLofBxUY6msfjXyJmF7A+OstbxQB15J8lnVAXEdLxwPnRVczBAeXP dkSQ2b0B6V7lLY48d/KxlbK/tC70rpgYzujOYygQfTPh9Q9DEosuprkl9G0Iiy99ud68 FhakJW7Zcn8ldT2KGcKZP5WNg0CqPcm1AeE9A/2826WnkWmXUr7S2BBrTjrwqt5RzW9l da5g== X-Gm-Message-State: AOPr4FUpI+e9E7TSbdltfMvy1wDzlV3yPy+3itZQgdIo9jC5+Axfm2BWHDXCmRu2yGjRUg== X-Received: by 10.202.75.82 with SMTP id y79mr1498529oia.71.1461696276980; Tue, 26 Apr 2016 11:44:36 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com. [209.85.218.49]) by smtp.gmail.com with ESMTPSA id u8sm90540obf.5.2016.04.26.11.44.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2016 11:44:36 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id k142so24886544oib.1; Tue, 26 Apr 2016 11:44:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.83.199 with SMTP id h190mr1706649oib.131.1461696276216; Tue, 26 Apr 2016 11:44:36 -0700 (PDT) Reply-To: cem@FreeBSD.org Received: by 10.157.6.111 with HTTP; Tue, 26 Apr 2016 11:44:36 -0700 (PDT) In-Reply-To: References: <201604251706.u3PH6okj031018@repo.freebsd.org> Date: Tue, 26 Apr 2016 11:44:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail From: Conrad Meyer To: NGie Cooper Cc: =?UTF-8?Q?Ulrich_Sp=C3=B6rlein?= , Jamie Gritton , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 18:44:44 -0000 Right. False positive. Coverity doesn't grok sbuf memory management fully= . On Tue, Apr 26, 2016 at 11:22 AM, NGie Cooper wrote= : > > > On Apr 26, 2016, at 11:03, Ulrich Sp=C3=B6rlein = wrote: > > > > 2016-04-25 10:06 GMT-07:00 Jamie Gritton : > >> 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 a= s > >> the current setup with allow.sysvipc is on. Jails and the base syste= m > >> 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) c= an > >> see the jail's IPC objects, but not its keys. > >> > >> PR: 48471 > >> Submitted by: based on work by kikuchan98@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 =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 } > > > > ** 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 >