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 4C06BC4332F for ; Mon, 7 Nov 2022 03:59:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69A278E0002; Sun, 6 Nov 2022 22:59:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 649D78E0001; Sun, 6 Nov 2022 22:59:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55FC58E0002; Sun, 6 Nov 2022 22:59:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 476FC8E0001 for ; Sun, 6 Nov 2022 22:59:43 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1AA861C6589 for ; Mon, 7 Nov 2022 03:59:43 +0000 (UTC) X-FDA: 80105292246.05.26D4D04 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf10.hostedemail.com (Postfix) with ESMTP id AC3F5C0004 for ; Mon, 7 Nov 2022 03:59:42 +0000 (UTC) Received: by mail-pl1-f180.google.com with SMTP id k7so9972900pll.6 for ; Sun, 06 Nov 2022 19:59:42 -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=1Q4ZmdhJ6TsgiYzPih6yeP4e/XpKNZWa9tZUio9xcGKuBuZNHGDPsSdgA+aCTr3NHS 3G6OhAQMECp3PzwbsPiR612fsiFHFdZpIKA3/t2PrvK1fFkzljU8aepGDBcokD02yoSX z+9ihaNI9bU2eZDY+ghBaxNtIGJdKQIyu95WBzvurntJY1TjhJgDpwT98oN6mtGbeXRN d54rxQrcu0rAwbBwHXXEYCprscOzXrpQg4xpvpZyG6lmN03hxsgJW0gyBjHh8z9Mj9ck t8qLGInFh9HwrfP2Afa0D5w7wcqzLcubiSEwCqLsmlHdvQEbAx0sHpCcrRMUZkpRWC58 XDAA== X-Gm-Message-State: ACrzQf0duIj+kquSyicFu2xVyBhyXny//D91bJftwF8bEACZMviy5WXW itIiR0EFaoDCFJ/hbbwsYI75cA== 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> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667793582; 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=tK5YyOubJwfiTVmlG1/f7tjG17kEPCWvBahIEcz+8l4=; b=4sTY0ox5391//PAnKVfxqFwGTVqtYndFLQIFfGfLn2DSeRrHZnlHRNhRsvBcD4BrjTm13Y HJEGCqrF9d+7OAJpbKByNllKosr+1pr/Cc/Onez/Seih/m41VFqT+sqkaVMbZ/A9w1HVOA KUTbUPa1u1q7aTEpjJo/8nwbzHjFhyo= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="ZyitcS/3"; spf=pass (imf10.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667793582; a=rsa-sha256; cv=none; b=Q/2Ma5eN3heJ8ifGbb0+miwP3crBvrn6c++5zyUpSMY1/zjY+1WN4mSK9UE0QxOg6GagxU fpC/NenzIzsRD2x0M8sPvGwxW46MMaTMnnmvs+nQpqeKXbQhWnOix2lOw1KNhIleF6yDzk W3zZHItIdeULYmSrEB2z9LyVB4PW160= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="ZyitcS/3"; spf=pass (imf10.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.180 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: AC3F5C0004 X-Stat-Signature: z83rss6fk8jc1emjmsyonw47xcuuax1t X-HE-Tag: 1667793582-288197 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 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