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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 251BCC4332F for ; Mon, 7 Nov 2022 03:59:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230349AbiKGD7p (ORCPT ); Sun, 6 Nov 2022 22:59:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230260AbiKGD7m (ORCPT ); Sun, 6 Nov 2022 22:59:42 -0500 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC039C62 for ; Sun, 6 Nov 2022 19:59:41 -0800 (PST) Received: by mail-pj1-x1029.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so8491889pjs.4 for ; Sun, 06 Nov 2022 19:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tK5YyOubJwfiTVmlG1/f7tjG17kEPCWvBahIEcz+8l4=; b=ZyitcS/3gs3aZQiGqG/Q7GbVOlc1TqzvFtgbdhE/AqyUaP1LLQq7PHRtclmapVQ8vj 8GKLXAi+Yh/h0uNE8dbF0XQ5AzmseEysJikeo/ZeIDRKV+Il03kMhToc8viko9/AmYul zcQ5Eeefg16RBLveRSsNajatDmqhu8tm32z4Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tK5YyOubJwfiTVmlG1/f7tjG17kEPCWvBahIEcz+8l4=; b=iZ+fe2Z/F7UXvdZE9PgpVlQDZtXu/GYcglnyppdddvVxuflrceGUHRv6Y4gIYwyK2i B33s85HezpJzu/ZOof1A8WPgLhD686LoB8ClUCJITbPdS552MwSNEVNvOq2RVjGs3ssf 1hq3AqStvxX3QNXv7JsJh+P575A797fJWKH8ZtBeF9UsdwkrwvTrpnrpkFWv+jrIR4Uo uLOLT7jJhEGYGuDoFAG9jtVjrSiMYP+b2eunpW7OPTXD4G5eBJ5ZJHiEW8z+UH19BF1e E/15IoGXt7RX/FzD3RaKQP7xpbuCtRXOjGG79dBxB5WeKOMeEJUqD5N26p9piPMS+fD+ lGZw== X-Gm-Message-State: ACrzQf0DeWMGYAYhPDV53c7SmWjI6K28dJ9EniXGuJp6OYgk6rJtpC5h y0WbTig7x+FzX+iyWyP3ZOpURA== X-Google-Smtp-Source: AMsMyM7lkEs6qetTh6BXX437KL+xR0SL7scTZP0rtLfxeDY1BHX12asImU0zz6Ln0CkKhKAchIwV2Q== X-Received: by 2002:a17:903:1207:b0:185:4042:23d2 with SMTP id l7-20020a170903120700b00185404223d2mr47766328plh.143.1667793581465; Sun, 06 Nov 2022 19:59:41 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id w13-20020a1709027b8d00b00186c5e8b1d0sm3807639pll.149.2022.11.06.19.59.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Nov 2022 19:59:41 -0800 (PST) Date: Sun, 6 Nov 2022 19:59:40 -0800 From: Kees Cook To: Pedro Falcato , David Gow Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, sam@gentoo.org, Alexander Viro , Eric Biederman , linux-fsdevel@vger.kernel.org, Rich Felker , linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com Subject: Re: [PATCH] fs/binfmt_elf: Fix memsz > filesz handling Message-ID: <202211061948.46D3F78@keescook> References: <20221106021657.1145519-1-pedro.falcato@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221106021657.1145519-1-pedro.falcato@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 06, 2022 at 02:16:57AM +0000, Pedro Falcato wrote: > The old code for ELF interpreter loading could only handle > 1 memsz > filesz segment. This is incorrect, as evidenced > by the elf program loading code, which could handle multiple > such segments. > > This patch fixes memsz > filesz handling for elf interpreters > and refactors interpreter/program BSS clearing into a common > codepath. > > This bug was uncovered on builds of ppc64le musl libc with > llvm lld 15.0.0, since ppc64 does not allocate file space > for its .plt. > > Cc: Rich Felker > Signed-off-by: Pedro Falcato Thanks for the patch! I need to triple-check this logic, as there have been some overlapping (or out-of-order) LOAD bugs in the past too, and I want to make sure we don't accidentally zero things that already got loaded, etc. David, has there been any work on adding a way to instantiate userspace VMAs in a KUnit test? I tried to write this myself, but I couldn't figure out how to make the userspace memory mappings appear. Here's my fumbling attempt: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=devel/kunit/usercopy I really wish KUnit had userspace mapping support -- I have a bunch of unit tests that need to get built up around checking for regressions here, etc. Anyway, I'll test this patch and get it applied and likely backported to earlier kernels in the next few days. -Kees -- Kees Cook