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 E9E1AC5478C for ; Tue, 27 Feb 2024 21:00:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 552676B0123; Tue, 27 Feb 2024 16:00:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 502C26B0124; Tue, 27 Feb 2024 16:00:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A3456B0125; Tue, 27 Feb 2024 16:00:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2A9256B0123 for ; Tue, 27 Feb 2024 16:00:30 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DCF83C0F16 for ; Tue, 27 Feb 2024 21:00:29 +0000 (UTC) X-FDA: 81838802178.29.08542D1 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf22.hostedemail.com (Postfix) with ESMTP id 165A3C001A for ; Tue, 27 Feb 2024 21:00:25 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709067626; 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; bh=BP8bJiq5dmrUd7UiCH251xGnF7lTC4ZFmIOi/hyLmfM=; b=ZFKjx+f3X6/wgFuwtkfhgDMIChk/SSfj+e5MrYyTALXkf4KCNe1OgDb2C9D1aknk1AgVAq et7qsVvPtjkP1ss/ykZopkFiQE7UDbn3X0aD/4sHy8mElr/fr3zBAWJzAAz0iSNcxIplIb 3inm0CYmZapWB+r+keeUektkNAxTOjw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709067626; a=rsa-sha256; cv=none; b=X2MI9dQmMYo7+Jep/Ps+zHXlm1yxIo2YUrAxGXhx33a5DU+GygThQRF8r2j+yngRUSE/fI rrgpcncQE3rRckBcEKiwSR+0Rjb0w3CRxYowDundcTI8K6BqY6G7TWg7hBWFR17EnBJFt3 7c4bnC0Lb/sUxmM7fjFy9MPrcOBeAQo= Received: from in01.mta.xmission.com ([166.70.13.51]:59646) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rf4Yo-004V6I-Ik; Tue, 27 Feb 2024 14:00:22 -0700 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:42108 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rf4Yn-005Syx-8G; Tue, 27 Feb 2024 14:00:22 -0700 From: "Eric W. Biederman" To: Kees Cook Cc: Jan Bujak , Pedro Falcato , linux-mm@kvack.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, linux-fsdevel@vger.kernel.org References: <202402261821.F2812C9475@keescook> <878r35rkc4.fsf@email.froward.int.ebiederm.org> <202402270911.961702D7D6@keescook> Date: Tue, 27 Feb 2024 14:59:54 -0600 In-Reply-To: <202402270911.961702D7D6@keescook> (Kees Cook's message of "Tue, 27 Feb 2024 09:22:35 -0800") Message-ID: <87v869pqr9.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1rf4Yn-005Syx-8G;;;mid=<87v869pqr9.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX1/DoQz7QJlvV3QX3of0uD+sm/D2JNl8PBs= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: Recent-ish changes in binfmt_elf made my program segfault X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspamd-Queue-Id: 165A3C001A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: rp5e97ce6xbaqjqkyrfntayqeojnzknx X-HE-Tag: 1709067625-499591 X-HE-Meta: U2FsdGVkX1/h8/62ZDonTTAwsSNLO23sMAATgs8AUWtfNH1oAbohqQSaKzwJWCAlaVeG/NTxKllskCXNMS3Wuu0xNHOtqpMLz7XOrcTtnC5LoWesUNJvI7nLO+SNNjgIGWGUxVGvFzM4Rhc+vVfW5L9C5m6yJeR+VYEQH/Re5y2Nb5FP07pFowuqUoklG5SLwJtzaH9aq4+i0VsJ8Z53+Nb8fbNwV26czflBiwRx0bNYUOl+b+2ctuV25idlMLouWEeDxznzo4PSmUWKPbcs/B2B0vUCFIKikkafBzSyuqt5bMQVmfppZ7oA8JKNpgqVtVCbIXK2aKo82AE4SxTVhcOpP7mMEddNvztjWe0P8uj8+N+0Oe3Ql9iLGmDl38NJaO4V0K2iANZ6gzYz1pnnTa2ivJhHdqFJIsmA/Y9ui9vUT0u8A3v4aVVdgAwhP5mKAQZ58OsuMCH+omD1ARuiuqFovkxk4X/wRKZciWVHi/Fkazyrv9Hr9Je7qfek/2tZBe9Q/VzRb/RGBBXS/asfqd5qnjnd+sZJK4lA1CmKmi0t2qs5kHOs6YaiUId9NbDbya+s7v4bAyr97mgEfhWUU72h+9cHeWQacWjp1kFs+Q/ZM0mJCEe3kJpnW5CIXLQMO50iyxi5AMhTjPesEVfo87P270x/X3ZdRAEslRcX9qJ+vhirugA98emUaO7gHpi3ekPqIfqdpeARiFMTSiDpGyUOJWyYeKPWxrAjT5spyCeMwNlquuTUq8+tMWlrk/QcWGyP4wVX0FHz6FCUgDYU/BveAqNt/Tkx+HQzNR2FodqusC2JC1p6i59AaFZUXZGUFXyv1XdYyNTTD29cxkr7yfkM/Y0tH1m5wHpN1Ka68dQlZeUavYn4r7CMJKGysFh38otyz2sLZvoD79ogRFXIzoxuC7tdU6kPCl3SUy57/VVRNKdmHAONzmU8ry4iHLIUK0fSgd+nz4Q41n2hxn1 Nkzic2Ov LsJWTFgKnI5qqcPlURgGxpunOAsijpeM3cUQvYYU4rYPQ2iDciJWsmZE5VJvTpLlYQOnSUv31gseGzZ5qAlMoGLC+3Mih8QTRJh/X+sFb/F+6fkMKFsJ+uKJjHrCPNa0vIZliYSXeGzJ36JJRPlI4648LbiZD2y9kbPsTEquSUvtOXlQY1dYHomNb9v9sZMMbWqVQXpwfXp2w+dKz77R1YhTiNuzIYJADDmBLXPlt8PB5TIVXCmPyxD/LAEiUMYGudmFSHl6/pEsZAxsiXQf2pnFoZ60OBvwVfj8oiwiGEF7mrgDxtsXplYrkO0nyV9LZTUfhHxbDYEQD/bCcI/5+Y83EPNW1xVQiMW1kanhl7gibleVgPrCVJg+hR1lpOMVO4BROYjlh9sP69bC765FJ6COzEB1ELgLnJyZnMVs4K4gyEn5eFU0xsObNQw== 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: Kees Cook writes: > On Tue, Feb 27, 2024 at 09:35:39AM -0600, Eric W. Biederman wrote: >> Kees Cook writes: >>=20 >> > On Tue, Jan 23, 2024 at 12:23:27AM +0900, Jan Bujak wrote: >> >> On 1/22/24 23:54, Pedro Falcato wrote: >> >> > Hi! >> >> >=20 >> >> > Where did you get that linker script? >> >> >=20 >> >> > FWIW, I catched this possible issue in review, and this was already >> >> > discussed (see my email and Eric's reply): >> >> > https://lore.kernel.org/all/CAKbZUD3E2if8Sncy+M2YKncc_Zh08-86W6U5wR= 0ZMazShxbHHA@mail.gmail.com/ >> >> >=20 >> >> > This was my original testcase >> >> > (https://github.com/heatd/elf-bug-questionmark), which convinced the >> >> > loader to map .data over a cleared .bss. Your bug seems similar, but >> >> > does the inverse: maps .bss over .data. >> >> >=20 >> >>=20 >> >> I wrote the linker script myself from scratch. >> > >> > Do you still need this addressed, or have you been able to adjust the >> > linker script? (I ask to try to assess the priority of needing to fix >> > this behavior change...) >>=20 >> Kees, I haven't had a chance to test this yet but it occurred to me >> that there is an easy way to handle this. In our in-memory copy >> of the elf program headers we can just merge the two segments >> together. >>=20 >> I believe the diff below accomplishes that, and should fix issue. >>=20 >> Signed-off-by: "Eric W. Biederman" >>=20 >> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c >> index 5397b552fbeb..01df7dd1f3b4 100644 >> --- a/fs/binfmt_elf.c >> +++ b/fs/binfmt_elf.c >> @@ -924,6 +926,31 @@ static int load_elf_binary(struct linux_binprm *bpr= m) >> elf_ppnt =3D elf_phdata; >> for (i =3D 0; i < elf_ex->e_phnum; i++, elf_ppnt++) >> switch (elf_ppnt->p_type) { >> + case PT_LOAD: >> + { >> + /* >> + * Historically linux ignored all but the >> + * final .bss segment. Now that linux honors >> + * all .bss segments, a .bss segment that >> + * logically is not overlapping but is >> + * overlapping when it's edges are rounded up >> + * to page size causes programs to fail. >> + * >> + * Handle that case by merging .bss segments >> + * into the segment they follow. >> + */ >> + if (((i + 1) >=3D elf_ex->e_phnum) || >> + (elf_ppnt[1].p_type !=3D PT_LOAD) || >> + (elf_ppnt[1].p_filesz !=3D 0)) >> + continue; >> + unsigned long end =3D >> + elf_ppnt[0].p_vaddr + elf_ppnt[0].p_memsz; >> + if (elf_ppnt[1].p_vaddr !=3D end) >> + continue; >> + elf_ppnt[0].p_memsz +=3D elf_ppnt[1].p_memsz; >> + elf_ppnt[1].p_type =3D PT_NULL; >> + break; >> + } >> case PT_GNU_STACK: >> if (elf_ppnt->p_flags & PF_X) >> executable_stack =3D EXSTACK_ENABLE_X; > > I don't think this is safe -- it isn't looking at flags, etc. e.g., > something like this could break: > > =C2=A0 Type=C2=A0 Offset=C2=A0=C2=A0 VirtAddr=C2=A0 PhysAddr=C2=A0 FileSi= z=C2=A0 MemSiz=C2=A0=C2=A0 Flg Align > =C2=A0 LOAD=C2=A0 0x003000 0x12000=C2=A0=C2=A0 0x12000=C2=A0=C2=A0 0x0010= 00 0x001000 R E 0x1000 > =C2=A0 LOAD=C2=A0 0x004000 0x13000=C2=A0=C2=A0 0x13000=C2=A0=C2=A0 0x0000= 00 0x001000 RW=C2=A0 0x1000 Yes. I think it should be modified to only do something is the break is not on a page boundary (which will automatically limit it's effect to where we need to do something for backwards compatibility). Still with a few tweaks and testing I think that is a good path forward for dealing with the ``regression'' case. Eric