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: 72213 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp182109qga; Mon, 18 Jul 2016 08:47:47 -0700 (PDT) X-Received: by 10.36.17.131 with SMTP id 125mr48861927itf.81.1468856867290; Mon, 18 Jul 2016 08:47:47 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o128si10043002itb.26.2016.07.18.08.47.46; Mon, 18 Jul 2016 08:47:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703AbcGRPrQ (ORCPT + 29 others); Mon, 18 Jul 2016 11:47:16 -0400 Received: from mail-qk0-f170.google.com ([209.85.220.170]:33284 "EHLO mail-qk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbcGRPrP (ORCPT ); Mon, 18 Jul 2016 11:47:15 -0400 Received: by mail-qk0-f170.google.com with SMTP id p74so160733609qka.0 for ; Mon, 18 Jul 2016 08:47:14 -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=ms8ulOi4AfbARuD0j+sRjkn2n3RzBDUU1ac3SQjpG7AzL7y616k1jjZOJ/u+ZN+tQW xIzxxwWhdh3rhsNrQ433XBNHVuQ94aAijMFx0s6ZDKEQrGxgnWoPvpI4NX8iwWh5a7tg IhWb+finxhKkBYRZC3dAZM4zXIPPvA428je/ZIupTHDHGSHCfhuIpGvmJZDYydxdWFdi 2D8C9pozUztulMIOihgry3lHRuRRAoxoEfr+SY9sXx7Qaz0hHx4xDfknFOysn+/q0Znf mz/iJVx9sH1st1gI3M0q15QS28rzajAsEGLbsO39p4OJt/HmyDaSoSx/ILsV1n02mQgS uOBg== X-Gm-Message-State: ALyK8tK4m2ES+av6M6z0VxeM55lxOtMKLw5GJ4iFN1gjSF6Asf8RpQ+368cktYwLDLqYyusO 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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 */