Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757468Ab2KVUGk (ORCPT ); Thu, 22 Nov 2012 15:06:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56695 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754179Ab2KVUGg (ORCPT ); Thu, 22 Nov 2012 15:06:36 -0500 Date: Fri, 23 Nov 2012 01:36:18 +0530 (IST) From: P J P X-X-Sender: pjp@javelin.pnq.redhat.com cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] exec: do not leave bprm->interp on stack In-Reply-To: Message-ID: References: <20121024232032.GA31129@www.outflux.net> <20121025123843.GJ2616@ZenIV.linux.org.uk> <20121026183601.GR2616@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1247 Lines: 36 +-- On Mon, 19 Nov 2012, Kees Cook wrote --+ | I think to avoid the explosion of request_module calls in the abusive | case, we could simply return ELOOP instead of ENOEXEC on max | recursion. -> http://www.spinics.net/lists/mm-commits/msg92433.html 1. returning -ELOOP has a side effect of not reaching to request_module() ever, for: == #ifdef CONFIG_MODULES 1415 if (retval != -ENOEXEC || bprm->mm == NULL) { 1416 break; 1417 } else { ... == 2. above patch does not seem to fix the 2^6(64) recursions issue, for: == + bprm->recursion_depth = depth + 1; retval = fn(bprm); bprm->recursion_depth = depth; == setting - recursion_dept = depth - again and the outer for(try=0;try<2...) loop seems to be causing the 2^6 recursions. Thank you. -- 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/