Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752541Ab2KRTFP (ORCPT ); Sun, 18 Nov 2012 14:05:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52890 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752291Ab2KRTFN (ORCPT ); Sun, 18 Nov 2012 14:05:13 -0500 Date: Mon, 19 Nov 2012 00:34:39 +0530 (IST) From: P J P X-X-Sender: pjp@javelin.pnq.redhat.com To: Kees Cook cc: Al Viro , linux-kernel@vger.kernel.org, Andrew Morton , Josh Triplett , Serge Hallyn , linux-fsdevel@vger.kernel.org, halfdog Subject: Re: [PATCH] exec: do not leave bprm->interp on stack In-Reply-To: Message-ID: References: <20121024232032.GA31129@www.outflux.net> <20121025041620.GH2616@ZenIV.linux.org.uk> <20121025120952.GI2616@ZenIV.linux.org.uk> <20121025123843.GJ2616@ZenIV.linux.org.uk> <20121026183601.GR2616@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1479 Lines: 35 +-- On Fri, 16 Nov 2012, Kees Cook wrote --+ | Hrm? It should be showing only the live heap-allocated interp -- are | you seeing uninitialized contents? I don't see uninitialised content; I see interpreter names from previous iterations. Which was the case earlier as well. The - interp - array is initialised with the interpreter name, before being assigned to bprm->interp. These - interp - bytes are *leaked* because after 4 recursions, when load_script returns -ENOEXEC, - bprm->interp - becomes invalid for it starts pointing to an invalid stack memory location. Crux of the problem is in the fact that the recursion limit - BINPRM_MAX_RECURSION(4) - exceeds after ones been rightly adhered to. (bprm->recursion_depth > BINPRM_MAX_RECURSION)) return -ENOEXEC; This check fails due to specific condition, which still exists. Dynamically allocating memory fixes the leak by making the memory area live and valid. It does not fix the problem which caused the leak in the first place by exceeding the BINPRM_MAX_RECURSION, not by 1 or 2 but possible 2^6 recursions. Isn't that performance hit? -- Prasad J Pandit / Red Hat Security Response Team DB7A 84C5 D3F9 7CD1 B5EB C939 D048 7860 3655 602B -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/