From owner-svn-src-head@freebsd.org Tue Apr 26 18:23:03 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 866B8B1C289; Tue, 26 Apr 2016 18:23:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 581141BBC; Tue, 26 Apr 2016 18:23:03 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22d.google.com with SMTP id n1so10962265pfn.2; Tue, 26 Apr 2016 11:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gyscpdnDskCLvJOgyP8lLOGBu9LEF+g6+/SsODOaUI4=; b=IhISIuTsixH8KycM8kS6Xx9+o4yOJpJa3FOC50ELEbtAcaoPkQEuCGAEdWUWddek8t c8yWevN6/s/wNJ2q/7Qvn3qQqpvQF2+i9Ch4oArglYmOUA2/7LGG/IW6Taf9oaVfuYZS JENDj3LFTq0rmNH9cR4RrqSXEnJVClohRjDbWnYyyF+NFwIhaCgIvoqZAg6vxfwyRzew seCFAoMz0pC+MimTe67iBx3WuslVOBxZq6W2v04y59ggCQLQ1ni++iDxwlXers6dzDB0 t4euY+I6Mzc/dn3xoFhozO1XQTH7uiZMz4+aGL6DW3rnm8z31yUzP2+rMgDdYTEkdXL5 CY9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gyscpdnDskCLvJOgyP8lLOGBu9LEF+g6+/SsODOaUI4=; b=CNV12MqrgwfadIUzGVcmGwKw/A8EDXIGyaBzhPTVv4sSQPrrObbnGu8PAVgoSpUgY6 WPgDTBm012RTQBDrRs3CfmrpuG71P0OdulNd2R8xfnV1e1KmUC6Pi8Ks4xPjb9ZwOZcy ad+SiCkZsYJ1qfa7WDYeuyF0uRV7Qc6bO9tha6ZgG/I1OveldNgv+x76jWDxpF4H5Iyd Ttxc6RAG8B9fTuwVpXunuOPbfx97cOrG+8JDWXBQKIwAwvndGNa8uBp4v6v60gg+iXhi jpN+dON6mEFE3Ia/tKzrdTnYBV4SJdC660nH2aB6bhnnTNvR/0wgJv8FzIR4iXznPh36 xCxQ== X-Gm-Message-State: AOPr4FVRlMC8TXe4ojcrjwANJDlP1fmWCRUZttm3Z7HlmMyqhxsUSS+lrLRvojkVb22LbQ== X-Received: by 10.98.66.89 with SMTP id p86mr5683194pfa.42.1461694982801; Tue, 26 Apr 2016 11:23:02 -0700 (PDT) Received: from [29.138.110.222] ([172.58.40.246]) by smtp.gmail.com with ESMTPSA id lz5sm141758pab.34.2016.04.26.11.23.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 11:23:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: svn commit: r298585 - in head: sys/kern usr.sbin/jail From: NGie Cooper X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Tue, 26 Apr 2016 11:22:59 -0700 Cc: Jamie Gritton , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201604251706.u3PH6okj031018@repo.freebsd.org> To: =?utf-8?Q?Ulrich_Sp=C3=B6rlein?= 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:23:03 -0000 > On Apr 26, 2016, at 11:03, Ulrich Sp=C3=B6rlein wro= te: >=20 > 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 >>=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=