From owner-freebsd-security@FreeBSD.ORG Wed Nov 7 12:36:57 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4EF5FE7 for ; Wed, 7 Nov 2012 12:36:57 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 54F198FC0C for ; Wed, 7 Nov 2012 12:36:57 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 3EC2C658A; Wed, 7 Nov 2012 13:36:56 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 0503B9093; Wed, 7 Nov 2012 13:36:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov Subject: Re: md(4) (swap-base) disks not cleaned on creation References: <20121106184658.GA24262@psconsult.nl> <20121106192704.GM73505@kib.kiev.ua> Date: Wed, 07 Nov 2012 13:36:55 +0100 In-Reply-To: <20121106192704.GM73505@kib.kiev.ua> (Konstantin Belousov's message of "Tue, 6 Nov 2012 21:27:04 +0200") Message-ID: <86fw4lio7s.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Paul Schenkeveld X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:36:58 -0000 Konstantin Belousov writes: > It is definitely not a security issue. I disagree. There may be legitimate reasons for root to create an md and give read access to an unprivileged user, under the assumption that it is zeroed; or to allow root in a jail to create mds. > That said, the following patch should fix the nit. I am unsure about > it, because it fixes mostly non-issue by spending CPU time to zero a > page which would be either zeroed or overwritten right now anyway in > normal usage. You can at least partly mitigate this by adding VM_ALLOC_ZERO to the flags passed to vm_page_grab() on line 666 and then checking the PG_ZERO bit in m->flags. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no