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 04B59C47DAF for ; Mon, 22 Jan 2024 16:44:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5438C8D0003; Mon, 22 Jan 2024 11:44:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F3FE8D0001; Mon, 22 Jan 2024 11:44:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3BB568D0003; Mon, 22 Jan 2024 11:44:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2C5728D0001 for ; Mon, 22 Jan 2024 11:44:11 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E3DA6C09CD for ; Mon, 22 Jan 2024 16:44:10 +0000 (UTC) X-FDA: 81707519460.04.83A32CB Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf09.hostedemail.com (Postfix) with ESMTP id 6282E140035 for ; Mon, 22 Jan 2024 16:44:08 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705941848; 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=F+uoqUvWFQKenmmc67Ptux1GGkJjGsS3wJE5Svq4uts=; b=Cw/s8U4+hR60Jn7cZBOliSXw42GPhp+bMYdXcsRb1Cb2m720g5btXuygjO7vSTOJjx/1BI Rh2n3mFnBD9lbuX4Zdr7AdS4reXFD8Rc3d4t3ToYwFwkVFAzAEs23OrzLbT46uuhaNyFWS HEiU2i8IFYaaIQdyef+qxEPPu8XmM+M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705941848; a=rsa-sha256; cv=none; b=etKrn2hcbvdJ/rLXPcg/+YvtZq8ZFQWKLpBhOap+BB7237FrRSxEpwYsoQ7p9vqDBYye3L fkM4KTGMv0Qnzi38TPpyRvKPGRJBMHuUQVPN9F/8lvyukKqLrB67O/N8U6gjP3m0Ti3o/Y a3brJxADpofhvxB7SojyRz3vW2xENcw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com Received: from in01.mta.xmission.com ([166.70.13.51]:40338) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1rRxP4-0021o7-AB; Mon, 22 Jan 2024 09:44:06 -0700 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:39350 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 1rRxP3-008l5j-AU; Mon, 22 Jan 2024 09:44:05 -0700 From: "Eric W. Biederman" To: Jan Bujak Cc: keescook@chromium.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, linux-fsdevel@vger.kernel.org In-Reply-To: (Jan Bujak's message of "Mon, 22 Jan 2024 21:01:06 +0900") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Date: Mon, 22 Jan 2024 10:43:59 -0600 Message-ID: <874jf5co8g.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1rRxP3-008l5j-AU;;;mid=<874jf5co8g.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/lma+EuFr0ycc+e9TktIXJpZ8FYTzs3UU= 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: 6282E140035 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: njasktzqahapnkckm39rfihj4y3sxyt1 X-HE-Tag: 1705941848-777159 X-HE-Meta: U2FsdGVkX1/m5Z2aqIDrUYBF6lFLlIGa6IzjLLxetWLhjQ9ewMP49W7YMDJI/ViiHyAz5Sid/tuNffPXyZDOUK88S1LoAVqFqsleVb1ZK2fO1ntDAENRDUWJDqqOC++zazod7czOcB3lcivQtS9GlQK20w+GhTFUgLd7xr4C1jJQ8zVPVpeDIkUel2l9nCvmthSjwtB8OyNVpnaueAT16oIbEYhXFUo+4awHBaWN3+zQkVr+M21O9nC+z/9gRuZDSUVIiWVZAb6E0Xmfyd8Uyp9CxwbRLuOz+EUulEafeK57hs+YIxIyNKargdYScSzDvVxRsThwNPsdaeEsy7/JnpIOJZLxyBWUzJ6sp/TIuRC9HaTNYIuY9/wrEMvrG1gD82+O7ChKo2EpbQQxzEm/2yQzmjoEQK2SyhBxexF63H+VzZBheLNh6XhQcF34NR7sDGLuP4u80FnrhzudhDxtDqzAOVyFz5B95duMWCTsOa2fBtHKpXjdY+T/+zRuxDVNxAcjk91bwRZkWybgyYQG9EWaSxDuRlBdsTBTjqOib5vNkCYim3yG6gBXhjKIQLmLZoqlW8vuW0NDARgcHLiZKTvIewc5kIuWDsP8oEPTfIKtAqDUqhTtn1OkJcb+fk8ZFnR3au266p0fv4knJDuPfEblwYrXg4txEfZUsKqTufM2I3n+EN7pabSo8q558oQVYFJE3q1K7dPOjQsaOs8ZtPKExYMNlxA93bB59TA9wj2NwsYh4Ox1z1fIkKGyJMd+k3ZPZ+duDyjPbanXyupkGtueDQlu/AoqA5P2WWKPd8TIDG1wm2ZYZ87uK7ywKsgprsIZdoU/d9nc2zgvl0zRWK8lvWUZJ5wopyqf81EqvS6o5Itltq/m/ct6ANyCs845wO1sH1m3yQDE3NHyg1uaptIUURvlM93kmI/tQKMH0Nmc0dvnGrZupFzAkI21ZfwrA6br/H/F2BL1x7zc04O +UIzNbxB jutq4fTi2KLZsSYpVbSWCvib1K2a0E5EHOxVAz4MGNMV6wNOotRwZnj3CWFLueXhlC7S8zlbkb5roLcAiQC8rGmv/xLK9wFpFAb/lLTI5E7pL4UVTS/14yuHs4CQoKsq02ZVr8KcTFD6nDw/JHoBRZ0gRyXfQp6t9MTpEfw21IQIXzCa+cT1CpXraMLigfjK04eaM4mW7RUTAd6A= 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: Jan Bujak writes: > Hi. > > I recently updated my kernel and one of my programs started segfaulting. > > The issue seems to be related to how the kernel interprets PT_LOAD header= s; > consider the following program headers (from 'readelf' of my reproduction= ): > > Program Headers: > =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 0x001000 0x10000=C2=A0=C2=A0 0x10000=C2=A0=C2=A0 0x0000= 10 0x000010 R=C2=A0=C2=A0 0x1000 > =C2=A0 LOAD=C2=A0 0x002000 0x11000=C2=A0=C2=A0 0x11000=C2=A0=C2=A0 0x0000= 10 0x000010 RW=C2=A0 0x1000 > =C2=A0 LOAD=C2=A0 0x002010 0x11010=C2=A0=C2=A0 0x11010=C2=A0=C2=A0 0x0000= 00 0x000004 RW=C2=A0 0x1000 > =C2=A0 LOAD=C2=A0 0x003000 0x12000=C2=A0=C2=A0 0x12000=C2=A0=C2=A0 0x0000= d2 0x0000d2 R E 0x1000 > =C2=A0 LOAD=C2=A0 0x004000 0x20000=C2=A0=C2=A0 0x20000=C2=A0=C2=A0 0x0000= 04 0x000004 RW=C2=A0 0x1000 > > Old kernels load this ELF file in the following way ('/proc/self/maps'): > > 00010000-00011000 r--p 00001000 00:02 131=C2=A0 ./bug-reproduction > 00011000-00012000 rw-p 00002000 00:02 131=C2=A0 ./bug-reproduction > 00012000-00013000 r-xp 00003000 00:02 131=C2=A0 ./bug-reproduction > 00020000-00021000 rw-p 00004000 00:02 131=C2=A0 ./bug-reproduction > > And new kernels do it like this: > > 00010000-00011000 r--p 00001000 00:02 131=C2=A0 ./bug-reproduction > 00011000-00012000 rw-p 00000000 00:00 0 > 00012000-00013000 r-xp 00003000 00:02 131=C2=A0 ./bug-reproduction > 00020000-00021000 rw-p 00004000 00:02 131=C2=A0 ./bug-reproduction > > That map between 0x11000 and 0x12000 is the program's '.data' and '.bss' > sections to which it tries to write to, and since the kernel doesn't map > them anymore it crashes. > > I bisected the issue to the following commit: > > commit 585a018627b4d7ed37387211f667916840b5c5ea > Author: Eric W. Biederman > Date:=C2=A0=C2=A0 Thu Sep 28 20:24:29 2023 -0700 > > =C2=A0=C2=A0=C2=A0 binfmt_elf: Support segments with 0 filesz and misalig= ned starts > > I can confirm that with this commit the issue reproduces, and with it > reverted it doesn't. > > I have prepared a minimal reproduction of the problem available here, > along with all of the scripts I used for bisecting: > > https://github.com/koute/linux-elf-loading-bug > > You can either compile it from source (requires Rust and LLD), or there's > a prebuilt binary in 'bin/bug-reproduction` which you can run. (It's tiny, > so you can easily check with 'objdump -d' that it isn't malicious). > > On old kernels this will run fine, and on new kernels it will > segfault. Frankly your ELF binary is buggy, and probably the best fix would be to fix the linker script that is used to generate your binary. The problem is the SYSV ABI defines everything in terms of pages and so placing two ELF segments on the same page results in undefined behavior. The code was fixed to honor your .bss segment and now your .data segment is being stomped, because you defined them to overlap. Ideally your linker script would place both your .data and .bss in the same segment. That would both fix the issue and give you a more compact elf binary, while not changing the generated code at all. That said regressions suck and it would be good if we could update the code to do something reasonable in this case. We can perhaps we can update the .bss segment to just memset an existing page if one has already been mapped. Which would cleanly handle a case like yours. I need to think about that for a moment to see what the code would look like to do that. Eric