From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752039AbcGXTtj (ORCPT <rfc822;w@1wt.eu>);
	Sun, 24 Jul 2016 15:49:39 -0400
Received: from mout.kundenserver.de ([217.72.192.75]:54767 "EHLO
	mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751268AbcGXTtf (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 24 Jul 2016 15:49:35 -0400
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
        Greg Ungerer <gerg@linux-m68k.org>, linux-fsdevel@vger.kernel.org,
        Alan Cox <gnomes@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org,
        David Howells <dhowells@redhat.com>, linux-m68k@vger.kernel.org,
        Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v5 12/15] binfmt_flat: allow compressed flat binary format to work on MMU systems
Date: Sun, 24 Jul 2016 21:48:55 +0200
Message-ID: <4262519.L4vdOGcrh0@wuerfel>
User-Agent: KMail/5.1.3 (Linux/4.4.0-28-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <1469374229-21585-13-git-send-email-nicolas.pitre@linaro.org>
References: <1469374229-21585-1-git-send-email-nicolas.pitre@linaro.org> <1469374229-21585-13-git-send-email-nicolas.pitre@linaro.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:A662kp0Quqq+4D/BtWNxGSij5B34SwJ7nEpBGDJbvEKtZ7Q2ukn
 WYacGnT8A0UN9Kd1HCpjUVhMXbURl3r4/X0weAT770Mlj6Bkoq/Ynd9vanRmRWNuqvujr/K
 wZil8qtrc+9ztUrm2+LmSLGIoJJglUDAnGuf8LT9MY0JfX9KJ4dqTZ4dBoAHs8+AZAp6yof
 xhOc2eAcnYEufbZChc4DQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:oMOVeEm/hu8=:c38KFUCl79VLOmylLGVkLv
 ewnEbZBsBC7A3kpLa+dbAMdVATC24XlI2kXzlO7WyipYpXl+8DMsi/vZ7vdKpIhJ2P2S0tJdR
 V94xrPbOTcxD2SIB0H/PcTFKeIRSqjJU9LUW8AJ0de8xd0p5po41x3lGBpbjHfUCybGxyeANK
 +CO011ScPcezEfGMz0en2m+RmWMfxDHHfZDHJepzzMkcX7e62lMO8mn7mSOQo+PRFzO9HBSE4
 b5hWlJFoJJNAKjCN/VBe/Q3g9DbU26WTM4qDwDx+kGMBE9/z7GIMrTh0Lu/2b1C3A6uleeQ+0
 ptntbVeOR57tK2KS5v1Mg7ztoYrRwTEGsrBnXFzlZdxiyogC0wpkDZncW3pbJUxvScELRMrmL
 nIAE14WvbHBTKRJmcvX6LjrLy5oWe01oiwnnXCBTwoQGvAuYWJtWtnRfgrA97ALwJcQ+qoRWE
 nQbvDpR7xcgJbittEfx2od5FTguY5uIwt20DZOWhAvGbJx44Fkg9BV8SnX/wV+mxdz/pO7fBZ
 XlbdBLx0VCFomL+wqUKoQbQN+M+NByvvF33oeJgUqHLCH2DjC7RD+T2LnAUChzUgZq58FlO/7
 hTTe7B8fE5pao8/OI1Si0hYQBbX3n+xtvx4VOzuPyzkQbV+RiMuWqQD6WE5CViJWSrfz4gQkR
 o7C/zMDFEZhOyZMsj8cBV5Vfy2TNMGm4mHWleqR2so6mimWvUxsnh556xZxe/QM5pk5Grd9UM
 lWyndMuA35D6EtU7
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sunday, July 24, 2016 11:30:26 AM CEST Nicolas Pitre wrote:
> +#else
> +                       /*
> +                        * This is used on MMU systems mainly for testing.
> +                        * Let's use a kernel buffer to simplify things.
> +                        */
> +                       long unz_text_len = text_len - sizeof(struct flat_hdr);
> +                       long unz_len = unz_text_len + full_data;
> +                       char *unz_data = vmalloc(unz_len);
> +                       if (!unz_data) {
> +                               result = -ENOMEM;
> 

Is there a risk of a malicious user exhausting vmalloc space with a
binary that has forged headers? If there is, maybe put an upper bound on
the size of allocation.

More broadly speaking, are there any other attacks that may get enabled
through forged binaries? We've had a couple of vulnerabilities in
binfmt_elf over the years, and I wonder how dangerous it might be
if distros turn on binfmt_flat support by default.

	Arnd