From patchwork Mon Jul 18 15:45:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 9234807 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6F8BB6089D for ; Mon, 18 Jul 2016 15:47:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 612F020223 for ; Mon, 18 Jul 2016 15:47:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4AFED26AE3; Mon, 18 Jul 2016 15:47:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DBA7526AE3 for ; Mon, 18 Jul 2016 15:47:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751707AbcGRPrR (ORCPT ); Mon, 18 Jul 2016 11:47:17 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:34284 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751437AbcGRPrP (ORCPT ); Mon, 18 Jul 2016 11:47:15 -0400 Received: by mail-qk0-f170.google.com with SMTP id o67so160807199qke.1 for ; Mon, 18 Jul 2016 08:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=eG4Z2bgru14JPTL7N4DQ24rGl0RqCMbDfDRxmY4sUVw=; b=OYVf9Zcma3MireiKrKIu+UlZKyuR/EGWwyzZUMtYRO+//naRNPpJIZe7ubbG7Rz5X2 LmjazYdcyhlL9/GADUCWnbeh/SSZ6A7c0SHPkieyLABVJiJoH0vwel7KUbPSmk6ReMhr 1p5q43VDM0lVvl+a6e9mV3UAx1mzyj7aDVXpU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=eG4Z2bgru14JPTL7N4DQ24rGl0RqCMbDfDRxmY4sUVw=; b=LHeHZG36vySNkdWejgFKCf+AiRm2QC7Ik5Id/DOIS37vvn/5BgirVCsrEgoPGLq8Gy /d7EvjpIcyYNu/Wky8AMTy+9UxraFjBBE4y69KPb8hoocG0uPDd0vBzQGdra8s39551x mFpxFOuaZrZHN0o+lhWSnc0JVFSLrRzCy9KUOyVa040BlsaStBnSxFVZv2UIa1QmYTzX OsPikd91mi+umEr/85ByNBeA0bDHTgdhSJ+ocbMx7AVnodceQ0Wc8Ix5ZuL+yGCYh5kI taiNg+3gxXwHgigkrRU19RfgYSJIf1DlgJOBAJfn21yK7o3sfQHTZ3lMDiYKrt1ibOnl k+UA== X-Gm-Message-State: ALyK8tJj0TTIroAj3yuVVBZz+/O7hhoMPjxOMT33bUTiu8NnyMoLfGWWDGKhMLbHnSMWZbxE X-Received: by 10.55.168.2 with SMTP id r2mr46136230qke.24.1468856834077; Mon, 18 Jul 2016 08:47:14 -0700 (PDT) Received: from Lenovo.lan ([24.114.96.243]) by smtp.gmail.com with ESMTPSA id e33sm1857030qta.47.2016.07.18.08.47.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jul 2016 08:47:13 -0700 (PDT) Date: Mon, 18 Jul 2016 11:45:53 -0400 (EDT) From: Nicolas Pitre To: One Thousand Gnomes cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Alexander Viro , David Howells , Greg Ungerer Subject: Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems In-Reply-To: <20160718124707.6adfa9a1@lxorguk.ukuu.org.uk> Message-ID: References: <1468812716-30537-1-git-send-email-nicolas.pitre@linaro.org> <1468812716-30537-11-git-send-email-nicolas.pitre@linaro.org> <20160718124707.6adfa9a1@lxorguk.ukuu.org.uk> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > On Sun, 17 Jul 2016 23:31:56 -0400 > Nicolas Pitre wrote: > > > Let's take the simple and obvious approach by decompressing the binary > > into a kernel buffer and then copying it to user space. Those who are > > looking for more performance on a MMU system are unlikely to choose this > > executable format anyway. > > The flat loader takes a very casual attitude to overruns and corrupted > binaries. It's after all MMUless so has no real security model. If you > enable flat for an MMU system then IMHO those all need to be fixed > including all the missing overflow checks on the maths on textlen and the > like. What about the following patch? This with existing user accessors and allocation error checks should cover it all. ----- >8 commit cc1051c9c57202772568600e96b75229a2a7cf19 Author: Nicolas Pitre Date: Mon Jul 18 11:28:57 2016 -0400 binfmt_flat: prevent kernel dammage from corrupted executable headers Signed-off-by: Nicolas Pitre > --- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index 24deae4dcb..fa0054c1c3 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -498,6 +498,17 @@ static int load_flat_file(struct linux_binprm * bprm, } /* + * Make sure the header params are sane. + * 28 bits (256 MB) is way more than reasonable in this case. + * If some top bits are set we have probable binary corruption. + */ + if ((text_len | data_len | bss_len | stack_len | full_data) >> 28) { + printk("BINFMT_FLAT: bad header\n"); + ret = -ENOEXEC; + goto err; + } + + /* * fix up the flags for the older format, there were all kinds * of endian hacks, this only works for the simple cases */