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 C7D11C433FE for ; Fri, 11 Nov 2022 03:59:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 45FF76B0071; Thu, 10 Nov 2022 22:59:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 410316B0072; Thu, 10 Nov 2022 22:59:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D7326B0074; Thu, 10 Nov 2022 22:59:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1F4446B0071 for ; Thu, 10 Nov 2022 22:59:21 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E72E81C6129 for ; Fri, 11 Nov 2022 03:59:20 +0000 (UTC) X-FDA: 80119806480.21.976C0E1 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf15.hostedemail.com (Postfix) with ESMTP id 8BC98A000A for ; Fri, 11 Nov 2022 03:59:20 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id gw22so3428475pjb.3 for ; Thu, 10 Nov 2022 19:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LgrIXUR8AU3qwrqhiw2jjUgSHNpYQrsvYDcBN102UbQ=; b=PSgjYIp1YjH3n3BqnVVZu+FCPYH7SSfo0UvMf8csT3kXBfM1I2a6YFvRhFx3PWk/NS yIWzvuuEED+AFAPS4Fyq4ShoziEHK/woObQ0BHBgUosVqjPtld1ArrZMEOARzrr8NWpx MSdrGNR4REGszRufFv+VS4KXkofyyrtqT/zulfT0YUzBE+HOQVXu4vOqdFZIXQG0bgnJ lnSBc/hLZRJHa3hiTBgMIHxrihPA35hiz4VmPN/8PNptKe/yg6Rq2mRwosEu7ITJe0bp PrwNO2WR8d/NuvWbTkU1sCSN0FSZQHiNrdmdpmRVQf+eqiSAfyzIT4efvb7GUUkl9chd LMJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LgrIXUR8AU3qwrqhiw2jjUgSHNpYQrsvYDcBN102UbQ=; b=hRD58rQ9iakf/S3YhNnWdzOD9IadW8Jo/77mDc6XMRJ1MLRbUDHAyH2FfZF4gg/LsC ewB7PzFwMq0+l7mWjYkXTwaFcG5iIqj9j/IrTqeSk3HiEQZvhUAwCB7D/3FjAxmB8luH wLjamuewjiTLIg/E6cNZKNq6V0jBWd1IBYTM4qrj7E75Ak8/cVL7UgR8sAFt+8SgfLuH 0N8RKr+KtCLNwUOrtAcAriu5DvKU17HB9BaWA5K0SRwcFhhZqtNpyiFQSlOQ2Eu3HSvu nxbc/IBARBtackjruBUdtqlw/OPT+DT+TJO/y3FR0d5c2+LTg8gQGLY3gxrXbhd8Kv8C 9xpQ== X-Gm-Message-State: ACrzQf0Am4o2/J3rwNGF2/GhQBlZRdx91cC2KixS5EFWsVo0De2sr4U6 TPFtAyU0xuUUuxrb0Mr6qvEfXIZBncyob9f3XiE= X-Google-Smtp-Source: AMsMyM5SUIHXONzylMWf1aJrJzXwrcq8UjA/TM8nmo3JZ/yvyj6NreOfMvpc+v6yPj54zjSuSsFvFPj787UIFaj7ZBk= X-Received: by 2002:a17:90a:64cd:b0:216:cdf6:54c0 with SMTP id i13-20020a17090a64cd00b00216cdf654c0mr3194897pjm.34.1668139159509; Thu, 10 Nov 2022 19:59:19 -0800 (PST) MIME-Version: 1.0 References: <20221108110715.227062-1-pedro.falcato@gmail.com> <202211101934.22CACD615@keescook> In-Reply-To: <202211101934.22CACD615@keescook> From: Pedro Falcato Date: Fri, 11 Nov 2022 03:59:08 +0000 Message-ID: Subject: Re: [PATCH v3] fs/binfmt_elf: Fix memsz > filesz handling To: Kees Cook Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, dalias@libc.org, ebiederm@xmission.com, sam@gentoo.org, viro@zeniv.linux.org.uk Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668139160; a=rsa-sha256; cv=none; b=t18uUyvsI9t/+O/LZoEU+QJ+9emOWmEwqHTpVCoSj4RetsqJJPlejHgakKiVCFksxZpve7 80GQeSpQ3XnouFx+yn9Yaq6gDpcOyKDpIb8KEjWU1QR7zA3v3TPM4UL+Uuwnbi2ZCWtejb XvhtWCoLTfWkYrABZSfWsJ6GWjRKaVs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=PSgjYIp1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668139160; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LgrIXUR8AU3qwrqhiw2jjUgSHNpYQrsvYDcBN102UbQ=; b=DY+YYOfR/5yV6/wmJypBArwgF8JxpwPwbs2WiWAJThMb1YQKkdO0Nw1caHtOZlaTXLCkFe dyoBIs9jUr54wVeXxNufULcMUmMuiAW0kWaBnucQ2W2puh+O76+PTHyXTSX7D+FY7wSAkZ pWLR1hU7ynfH9zL9c7Y13ysfj9vHV2c= X-Rspam-User: X-Stat-Signature: 3ijb8wpy7o1yht7cjwcyse5p9r79f14x X-Rspamd-Queue-Id: 8BC98A000A Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=PSgjYIp1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1668139160-184109 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: On Fri, Nov 11, 2022 at 3:38 AM Kees Cook wrote: > > On Tue, Nov 08, 2022 at 11:07:15AM +0000, Pedro Falcato wrote: > > [...] > > + * This tail logic is skippable if we're the last phdr, as > > + * nothing can map an address >= our p_vaddr, since ELF phdr > > + * PT_LOAD segments are required to be sorted in an increasing > > + * order. > > I'm still looking through the patch, but I do want to call this bit out > as a problem. The kernel cannot, unfortunately, make this assumption. See: > https://lore.kernel.org/linux-fsdevel/YfOooXQ2ScpZLhmD@fractal.localdomain/ Ugh. I guess it doesn't matter in this situation? That logic only matters if we're trying to fix this new loading bug, and old executables load correctly with the old behavior anyway, which is what you get if that logic falls through. I don't know if this makes sense, but in my (possibly naive) opinion we have a compromise to keep loading what could already be loaded, without actually requiring to load broken ELFs 100% correctly. We could of course also just sort the program headers at load time, but I assume that's unwanted overhead for most well behaved ELF program headers :) -- Pedro Falcato