Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1610156rwb; Thu, 10 Nov 2022 20:01:54 -0800 (PST) X-Google-Smtp-Source: AA0mqf62pzkzbSkQHIh9WWOAmgkFwNxbKYcroLrp1Rlv5LSxB/3JLRwJtzrxFyDXOr+qeMkNpSe6 X-Received: by 2002:a63:d90c:0:b0:46f:2780:93b7 with SMTP id r12-20020a63d90c000000b0046f278093b7mr34136pgg.166.1668139314578; Thu, 10 Nov 2022 20:01:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668139314; cv=none; d=google.com; s=arc-20160816; b=OIXJ4W4nF/gpj8ZOYN7nAux4mBhrBCi/D9ao+FqH3NDypp14TfO6Hh5BS4xJ8r6aSe 6ZSb9tYcrCoK6iSKyPOpVMBxJPSxeWY17Bb5tyzohVYmdTTLhD+kUdcFdsn+tg7xMmgF Q7gBCCCzRf0NtgwWwNxFY3CcLPwK1O/A9GtK3PDoyNRVF7Qzbz78L4uHm9+06tJoGJX7 gcrfN0pXz0g6MPsVZFcsUF91+MmkQOtYpxh7Sk4Ecfrl1eq0GS5g3gncf3aYlcqgP8YF nPfA8asTUzOdbi2njr3r90phUbn+ew7yvM+7rZgsW5ebPlYFdq2kZLatHLEMCD02eYRA h4fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=LgrIXUR8AU3qwrqhiw2jjUgSHNpYQrsvYDcBN102UbQ=; b=YUcQcRVivvkuwEi9n/TZsCd3wxdPEzq1VWkR3F0edo5xVdh9awRg0eTyUtfbB1MjK3 7twNqgYLuZNuM3WGZfmMjkjhErDJCfYOI89MAjbY1/2TVtfl0vY5QBZRm727+YUfYteD GVFH9Rw8RnDdtMW35aLUTjyMq6qsbul5BIO4Vs4Ut9GeaWcxtIBN4EEPGBOWs+IVmWm1 1KIuvKmbEDCnibOnNrQb9D2gxzVQPsBuAYJ3nU6Do3weySaJxKX2OmHPi77Fg7XVOYQu z4LilFMjBhvdNEz6XlSeoxoSArE6Sn2PU7sS+6KX8H51dZFmgw7UD0RnxIvr+Y2/bHX1 Tjng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=PSgjYIp1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e6-20020a170902b78600b001732b4e99c4si1222208pls.377.2022.11.10.20.01.41; Thu, 10 Nov 2022 20:01:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=PSgjYIp1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232094AbiKKD7W (ORCPT + 93 others); Thu, 10 Nov 2022 22:59:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229907AbiKKD7U (ORCPT ); Thu, 10 Nov 2022 22:59:20 -0500 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 168B0D119 for ; Thu, 10 Nov 2022 19:59:20 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id j12so3283330plj.5 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=i6uwC/lZev4dlS7yvQ8QnHIP+qA4q3WWDXpUkQQ3qVFq456j0FTHD8UH3tpKKCqANw K1XzCRypKdkHzJozza2F1WSGGmq/Zz7Ll6cnijFYxHOnZAHtyFOqniok4KhYlo/TB+FX 26II4eTigw/K0s2jkzeycyto5EIkB1ucxktyfFOrx28vUfllsTHk7ySDH4as2Qy5KdQf VVv0jEYxfGu3Mtmc0zrFJLS72+h33ydKrcenln+/1MDvLFKtRxTzpao/igUsXq2wVxFs GQbkpEKp6DWVYHxZ6UcNlktrSjxqBIehOCq5lTOGVaF1KT6lav0Jin2quGgg9OdUuN4z SfyA== X-Gm-Message-State: ACrzQf10KFmQIyP1clU932pfQ7A9sD9EtON7xyaRm8/wu517+V9t/DPV IH25kC49esqTpOnhJLJlEcWdvQDg22BPrhR6/AQ= 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" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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