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 D63A5C54E58 for ; Thu, 21 Mar 2024 19:52:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19D706B007B; Thu, 21 Mar 2024 15:52:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 126E06B0082; Thu, 21 Mar 2024 15:52:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F305A6B0083; Thu, 21 Mar 2024 15:52:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DD85A6B007B for ; Thu, 21 Mar 2024 15:52:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3F6CA1C1886 for ; Thu, 21 Mar 2024 19:52:31 +0000 (UTC) X-FDA: 81922093302.26.AA4E0E8 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf26.hostedemail.com (Postfix) with ESMTP id 6B20914000D for ; Thu, 21 Mar 2024 19:52:29 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hTTg761T; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of jcmvbkbc@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=jcmvbkbc@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711050749; a=rsa-sha256; cv=none; b=hZ7dChOtajh9J1up3BHzco1AKqMatIEZ7tee5WuDMupjEDW1H8oFZ62xldPe8WVpTXmDHN oBU7OmzYWjGG5TLYd6djyhdfjJyOk8rMG4ROy71/6NFUvWJrtPRZ4jmVhLN4u3DAfCMFf4 wZS9CS3sSRmUM5IgpxmjQXKd8LHV5q4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hTTg761T; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of jcmvbkbc@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=jcmvbkbc@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711050749; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7g9NCGY01ymluNhJoggsG8hQO99YWuEg4encn9wbinI=; b=BVpGWWj51b+rlvxsBcHurbBqS92awJwXWgatdBUYVCEtjVI9krg/3CPYovuDGxzVgJjAqo ZDMPBH/KUI9nQ/62rpiw2nr8VHpCyhI9PkQYLUOnBquZqVa8Pa1UJrW166vquqLYc/66fU +AdSyloTaE4IQgU4JqK1ueN1Thlgk2Q= Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6e703e0e5deso1029059b3a.3 for ; Thu, 21 Mar 2024 12:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711050748; x=1711655548; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7g9NCGY01ymluNhJoggsG8hQO99YWuEg4encn9wbinI=; b=hTTg761TXQbi8lSlIj5mP+5x8TI5VRe5Fm64jdTWp1A/4mHcPGLce3erG12H5Em1AC 7i1+9DQxjAGNqGpaZXZvYpUnHFr5c8KO8fcwldxwfo2namPOhMctGTUCSxZ3UnJ+fImQ MVtJnHbrw4u7gjcH29Ts8Il186xf6at/KeUFg3ah77XmNB8hLk5mmiJvqB51evhweIzY 8HpaJ++oRwnwVztXuR0HdnGo/JBgrllFqBG/9EcVnd2waF6QiB7Se7nrVmFVObk0AQwc JMoX8y8UL5ICwBzVN2oVbI5APOS9bn65hyJPs6oCMHzfAHhTMg5YiEWH9Q8An/9wLXag 5LFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711050748; x=1711655548; h=content-transfer-encoding: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=7g9NCGY01ymluNhJoggsG8hQO99YWuEg4encn9wbinI=; b=Mc2Sq9UPwQXboBM2stGvqrsaA2GhVGNU0GRD3qhSNkESUMbiSQTcak+w4myRCAdY54 7A/VAaHJe31YDdvnAJ6BCjqkaOdlj05cBXpZFtgknDaaQJckliTjWFYM1WSwxWs8r8K8 ygKPAQwIegR+DtVssM/bwHQx4q1PELK5T/l9Qum8tAK/iBqkuBfLWiRgYXJKYdYEswrB nvz1f7j5OufNlaaQ9XeA/Ug0N5etZaSMqppJ2UPYQagmYEG0xZyMlMZ/iJzPxPKVdIpb FP71q9Us00IUlUXdhXPp2Dek5jEdr+E9smpiG1chDMkMwpfvJREn2qplFQvc3lW52TEB TrFQ== X-Forwarded-Encrypted: i=1; AJvYcCWFR7s3yCL/jDoKpY8YZRqeqQwhX8V8zJYXpoGdIqdJvLZIqgF11J30mUoxsQffGzoXt5baMOmCQfNu5lChnGK/Hps= X-Gm-Message-State: AOJu0Yy49RyXTCQ4NEC1UijFbnHqsFDkSg+QCgkhSUU6vhKrF9PvHy9C yzDoSNDl+zOtVrR/5p4JvKJEnxb42tARDfF+Q7XXCKtcoy7UoR9xk622/KzqcDsQXbUOP9viB7+ SKJF2mqMoxjrhY/hwD9PM9KC1XVw= X-Google-Smtp-Source: AGHT+IHeRGYnu8OY3eiPPYKq0YGvx2izwmmbVrGCsmBFaLYt0yE8OEZ9pzFlZGLmywWhWPikpexuKk1/hqI8uulgA4o= X-Received: by 2002:a17:903:230f:b0:1dc:51ac:88f5 with SMTP id d15-20020a170903230f00b001dc51ac88f5mr434224plh.65.1711050747888; Thu, 21 Mar 2024 12:52:27 -0700 (PDT) MIME-Version: 1.0 References: <20240320182607.1472887-1-jcmvbkbc@gmail.com> <202403211004.19F5EE27F@keescook> In-Reply-To: <202403211004.19F5EE27F@keescook> From: Max Filippov Date: Thu, 21 Mar 2024 12:52:16 -0700 Message-ID: Subject: Re: [PATCH] exec: fix linux_binprm::exec in transfer_args_to_stack() To: Kees Cook Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Eric Biederman , Alexander Viro , Christian Brauner , Jan Kara , Rich Felker , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6B20914000D X-Stat-Signature: wxszeknfk61jt7xwf9e76x3g4nszc1qm X-HE-Tag: 1711050749-196386 X-HE-Meta: U2FsdGVkX1/Hav6ICLaLhRlHr/QbRA7wMx//N4y1WjcGFAiAi57qvcTTxJr801xzeXTTnK5qw6eRSR7Dl++jDmD4eNBZiM9hQFEM3Ba6wvJk2+yvhG8b546I6as3SObo5ze5jAF/vvKQUQhfz2KAWvWvLzy9rsdcNx+ct/Grrz3z31fGuIOcoSuZpGnes+iDlUCgwmzEttVVP4yocvxUGpiWDEHBU2diI/Ao/ombDPfHkZq8m+Hln85t2Tdp4+b6M97MnmuKqyhKE7ELOwvOmewSzU+7HgNy1gNFUGM5AwSIWYN6hHo898stdQ30rfUNYyHu7tV4rCJvHTI1Ljj+gpkI9RasACvRN+JyEZWmwM7z0KE0melgBo0Ex3ixk4nnxKWDcXneO4gb11ubzxId+L14p+hsneUftHldnj/FhiuTpGKQTi5neg1alTsnL9AHU3MaWOyXZsJeM+10SKS8q5jeVlTIdB4My1qP3+/vqm3RTDJda7KkwX4/tVFFDdXrJt+rKVWoaZ1d8bSAB9qb5B9zxQ9Ik44kU9g+hZBlADTQhox0xQuWAq5HJolX6dyA02W7VSjyLtNAmBcn+9jlstBtvhNTZkXIjsWtmEMITwSRB1dvZM6mRTF9Pq+8XC+dEMxBanGDcGUJ2mn+k10trSO2ISoNX2FGFsrscgSnDGYI6x0T7QbYQW2+kkC99kjmRDTZcihV4EVWEIg6P8lx4JZjydOdLp9HJliGEN+hytXCHcR6iRss2jjBHwi3cfOuW6j3Re6dJjEroKaISeYpbtJ5YhLoY4iezXUyMaSiGwj2T6sqcceoe2F/UsNsjepJ4qERX4RDBxym12gk3TZeYE00UJ2hH/59Xv7IUtxLHeGRzuMJ0TyS3xfb+85K0NEnbc9hk+Iolmk7iC0PNPdvNWmDEbNTj4IZuU4/a1trjY7mW4hmulJfpS9H2cV6HlBgBhBaDJMyJA1t87qhJL6 m0M0CxYh PF0qcupx3f0C09ld/dWmbBcIa3wXzwoEPyfGsQPWlWnfmbP/LHVq9V5TfFCyvUhi5dD3W3paGvfF88UyfI/vqYD/qN4hAmzk9TefGAqd2DhcNADDlXqulNoDjiiVane5xxnQFM39x7OBbKjQ/tkBsrIaqc+UdDLWPgHyro2orV4XK4ippMPaygLjbRk4HUvrdKyPwPdtLBT8+w0UL8P1AkLKp/6jagH65KJUiD7Gy1LkWdtdQVIeI768HInE5od157TmXJuH295ckK5reAWhY6kHl5hTGCV6odrBlZGMYbn8a4ykC+Y9oEYG8pEaZb1YH9BDQ0awImsBP9kVc6cXMoiyHjBnG8vVVJLuhCqPkLLSiQ+/hcnAqRlxw6cR+YDLt8ZlAfwNbn0990U5I9ga01BWrgNpVyd3Xd8wUUrAnVoeagcjnZNRJTTmHrEa1RG41TrX5PTLocEDN1Y/5Wgpfm4UajHw0RN5vVeP1KHcQlUgODo2/0+7WEcT38AoyZtzRjLd40rT4lyG2Mlxj4cNuWQsxu9xS80euDFez52hk7k8fwuc8RLxHeCU51/JVwai0vbFT 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: List-Subscribe: List-Unsubscribe: On Thu, Mar 21, 2024 at 10:05=E2=80=AFAM Kees Cook = wrote: > > On Wed, Mar 20, 2024 at 11:26:07AM -0700, Max Filippov wrote: > > In NUMMU kernel the value of linux_binprm::p is the offset inside the > > temporary program arguments array maintained in separate pages in the > > linux_binprm::page. linux_binprm::exec being a copy of linux_binprm::p > > thus must be adjusted when that array is copied to the user stack. > > Without that adjustment the value passed by the NOMMU kernel to the ELF > > program in the AT_EXECFN entry of the aux array doesn't make any sense > > and it may break programs that try to access memory pointed to by that > > entry. > > > > Adjust linux_binprm::exec before the successful return from the > > transfer_args_to_stack(). > > What's the best way to test this? (Is there a qemu setup I can use to > see the before/after of AT_EXECFN?) I put a readme with the steps to build such system here: http://jcmvbkbc.org/~dumb/tmp/202403211236/README it uses a prebuilt rootfs image and a 6.8 kernel branch with two patches on top of it: one adds a dts and a defconfig and the other is this fix. The rootfs boots successfully with this fix, but panics if this fix is removed. The easiest way to actually see the AT_EXECFN is, I guess, to do something like that: ---8<--- diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c index fefc642541cb..22d34272a570 100644 --- a/fs/binfmt_elf_fdpic.c +++ b/fs/binfmt_elf_fdpic.c @@ -659,6 +659,7 @@ static int create_elf_fdpic_tables(struct linux_binprm *bprm, NEW_AUX_ENT(AT_EGID, (elf_addr_t) from_kgid_munged(cred->user_ns, cred->egid)); NEW_AUX_ENT(AT_SECURE, bprm->secureexec); NEW_AUX_ENT(AT_EXECFN, bprm->exec); + pr_info("%s: AT_EXECFN =3D %#lx\n", __func__, bprm->exec); #ifdef ARCH_DLINFO nr =3D 0; ---8<--- > How did you encounter the problem? I'm doing xtensa FDPIC port of musl libc and this issue popped up when I began testing it on qemu-system-xtensa with the real linux kernel. Related post to the musl ML: https://www.openwall.com/lists/musl/2024/03/20/2 -- Thanks. -- Max