From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 74D83C433EF for ; Sat, 5 Mar 2022 11:28:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B2F18D001C; Sat, 5 Mar 2022 06:28:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6624A8D0001; Sat, 5 Mar 2022 06:28:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 550B08D001C; Sat, 5 Mar 2022 06:28:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id 42C9E8D0001 for ; Sat, 5 Mar 2022 06:28:39 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E843A9D676 for ; Sat, 5 Mar 2022 11:28:38 +0000 (UTC) X-FDA: 79210109916.21.4F10C55 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id 5F94320007 for ; Sat, 5 Mar 2022 11:28:38 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8B272611A6; Sat, 5 Mar 2022 11:28:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 621ECC004E1; Sat, 5 Mar 2022 11:28:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646479717; bh=axBIQiXslDRfoPR3l1usFttL4/IG+TZ9GxXXL+ShLDQ=; h=Subject:To:Cc:From:Date:From; b=nflJmdYoGAmhTUOOs5HFBY94G7FtLdYDTX3mM/oRvyuEe32Q0FiMeicXj/bZLkjbY nWTTFq5n3qDOL7drz6/PwG9tHTRdjlht35n2XA9LteHGApN/EhT+k3GIJLZUkm1XjQ YqopaGsP74/niFxdp4GQHDl/T+X0PrBEJgGNiaqI= Subject: Patch "binfmt_elf: Avoid total_mapping_size for ET_EXEC" has been added to the 5.16-stable tree To: ebiederm@xmission.com,glaubitz@physik.fu-berlin.de,gregkh@linuxfoundation.org,keescook@chromium.org,linux-mm@kvack.org,matoro_bugzilla_kernel@matoro.tk,matoro_mailinglist_kernel@matoro.tk,viro@zeniv.linux.org.uk Cc: From: Date: Sat, 05 Mar 2022 12:27:34 +0100 Message-ID: <164647965420427@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ANSI_X3.4-1968 X-stable: commit X-Patchwork-Hint: ignore X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5F94320007 X-Stat-Signature: sob1h93ansrsaueopwuk8h6i5zak5ikz Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b=nflJmdYo; spf=pass (imf13.hostedemail.com: domain of gregkh@linuxfoundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org; dmarc=pass (policy=none) header.from=linuxfoundation.org X-Rspam-User: X-HE-Tag: 1646479718-549100 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This is a note to let you know that I've just added the patch titled binfmt_elf: Avoid total_mapping_size for ET_EXEC to the 5.16-stable tree which can be found at: http://www.kernel.org/git/?p=3Dlinux/kernel/git/stable/stable-queue.g= it;a=3Dsummary The filename of the patch is: binfmt_elf-avoid-total_mapping_size-for-et_exec.patch and it can be found in the queue-5.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let know about it. >From 439a8468242b313486e69b8cc3b45ddcfa898fbf Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Mon, 28 Feb 2022 10:59:12 -0800 Subject: binfmt_elf: Avoid total_mapping_size for ET_EXEC From: Kees Cook commit 439a8468242b313486e69b8cc3b45ddcfa898fbf upstream. Partially revert commit 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE"), which applied the ET_DYN "total_mapping_size" logic also to ET_EXEC. At least ia64 has ET_EXEC PT_LOAD segments that are not virtual-address contiguous (but _are_ file-offset contiguous). This would result in a giant mapping attempting to cover the entire span, including the virtual address range hole, and well beyond the size of the ELF file itself, causing the kernel to refuse to load it. For example: $ readelf -lW /usr/bin/gcc ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz .= .. ... LOAD 0x000000 0x4000000000000000 0x4000000000000000 0x00b5a0 0x00b5a0 .= .. LOAD 0x00b5a0 0x600000000000b5a0 0x600000000000b5a0 0x0005ac 0x000710 .= .. ... ^^^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ File offset range : 0x000000-0x00bb4c 0x00bb4c bytes Virtual address range : 0x4000000000000000-0x600000000000bcb0 0x200000000000bcb0 bytes Remove the total_mapping_size logic for ET_EXEC, which reduces the ET_EXEC MAP_FIXED_NOREPLACE coverage to only the first PT_LOAD (better than nothing), and retains it for ET_DYN. Ironically, this is the reverse of the problem that originally caused problems with MAP_FIXED_NOREPLACE: overlapping PT_LOAD segments. Future work could restore full coverage if load_elf_binary() were to perform mappings in a separate phase from the loading (where it could resolve both overlaps and holes). Cc: Eric Biederman Cc: Alexander Viro Cc: linux-fsdevel@vger.kernel.org Cc: linux-mm@kvack.org Reported-by: matoro Fixes: 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE") Link: https://lore.kernel.org/r/a3edd529-c42d-3b09-135c-7e98a15b150f@leem= huis.info Tested-by: matoro Link: https://lore.kernel.org/lkml/ce8af9c13bcea9230c7689f3c1e0e2cd@mator= o.tk Tested-By: John Paul Adrian Glaubitz Link: https://lore.kernel.org/lkml/49182d0d-708b-4029-da5f-bc18603440a6@p= hysik.fu-berlin.de Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman --- fs/binfmt_elf.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -1135,14 +1135,25 @@ out_free_interp: * is then page aligned. */ load_bias =3D ELF_PAGESTART(load_bias - vaddr); - } =20 - /* - * Calculate the entire size of the ELF mapping (total_size). - * (Note that load_addr_set is set to true later once the - * initial mapping is performed.) - */ - if (!load_addr_set) { + /* + * Calculate the entire size of the ELF mapping + * (total_size), used for the initial mapping, + * due to load_addr_set which is set to true later + * once the initial mapping is performed. + * + * Note that this is only sensible when the LOAD + * segments are contiguous (or overlapping). If + * used for LOADs that are far apart, this would + * cause the holes between LOADs to be mapped, + * running the risk of having the mapping fail, + * as it would be larger than the ELF file itself. + * + * As a result, only ET_DYN does this, since + * some ET_EXEC (e.g. ia64) may have large virtual + * memory holes between LOADs. + * + */ total_size =3D total_mapping_size(elf_phdata, elf_ex->e_phnum); if (!total_size) { Patches currently in stable-queue which might be from keescook@chromium.o= rg are queue-5.16/selftests-seccomp-fix-seccomp-failure-by-adding-miss.patch queue-5.16/binfmt_elf-avoid-total_mapping_size-for-et_exec.patch queue-5.16/ucounts-fix-systemd-limitnproc-with-private-users-regression.p= atch