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 70489C47DD9 for ; Mon, 22 Jan 2024 20:48:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6EBB6B00B5; Mon, 22 Jan 2024 15:48:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D1F7C6B00B6; Mon, 22 Jan 2024 15:48:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE6A36B00B7; Mon, 22 Jan 2024 15:48:12 -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 AAE066B00B5 for ; Mon, 22 Jan 2024 15:48:12 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 15D9FA1BD4 for ; Mon, 22 Jan 2024 20:48:12 +0000 (UTC) X-FDA: 81708134424.01.AC39041 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf17.hostedemail.com (Postfix) with ESMTP id 296A440012 for ; Mon, 22 Jan 2024 20:48:08 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PZTn9dQX; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.182 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705956489; 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=nXbpsEnHClGHGXt9fUpUqdjWwEkQ1678gxMm5C6Enb4=; b=kF1kgMedEPyKzTZufYVxTMtmQ7uwUH4vX5lUEKZ2wznn9YG2qLOistP3ExvHKdDpl7WfVc SaHGCeLbJHtx3V4+zGg1FAvloKas6tvqhTd9TIek7z09K9TvLzqS2CUhcMGYpqYdI3WTkh O05AvY0Ae8nfvf51bcmuU8irtgj94Ao= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=PZTn9dQX; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf17.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.182 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705956489; a=rsa-sha256; cv=none; b=e75t7FT3ZnAXXWSumkoX/nSQKoFSfe7wMjxb7w3CPDZvzlP4CjXNlMf/PHhiIn6k3fMb3A gwzxHfMNjK4UfJEZLakLesnUyjqFlnUqaQGdaDY8RjSTWQVl6iZM88ygObjCs2PR0nugml DYr6gtfqXMnwWdfCd2WWvsl2Mtc8sIA= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-5c65ca2e1eeso1690334a12.2 for ; Mon, 22 Jan 2024 12:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705956488; x=1706561288; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=nXbpsEnHClGHGXt9fUpUqdjWwEkQ1678gxMm5C6Enb4=; b=PZTn9dQXUIX4Zq7iFfrjgGrVeZOrdls/v9KMzXPbkXRKzwFhp4eFEwhw2mXHgdsfqZ x7VYHVkx/NC4b4EwjDL5OQu8NUsQdnteXs/4zwPx/P9eFZePDWiS831HGWzxbVAoUSe1 QiD/j+gonoBIoZxzNpTY33COHzmdFMs40TdaI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705956488; x=1706561288; h=in-reply-to:content-transfer-encoding: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=nXbpsEnHClGHGXt9fUpUqdjWwEkQ1678gxMm5C6Enb4=; b=OV9u9DgJd8u1d2UQ1EqjbFtLly17WYyG9mPO+Wd3sMD8YUcuYncGyjdFo4hmYt1i6S ogZHkUncd9145xS3Dsb8h3+2Q4yEENWt4xiomWNDqgtlfA+q1yl+A6dv5mGkJJIUgDdC QflCIPmU9mOn5pILcyTV81Iuw8Flc+gkuOGBpDwwWOUPKUUQNXRJx1yHaS7brpugTwVq rLdTDH8nR+Wp0WOv6x+Jky/nNpzGqrVN1Ik8mYML8QRT9/lmtQscv/D0ysdHZXOsRR68 xgEDmIiklXi1Msqeu6OUURd7EyygWufv/g3Nb3rA5rL2Hx8g+7wyhERPlDvcORcXd954 PMTw== X-Gm-Message-State: AOJu0YxHyCxGp4CDJ0w/f+rJc/3pm1WO7lYjDBfAqS/v1mAaDtA06M6V FU9WTGBQDMNnNMnXw1g42PmVS/1Vt+fmsS2xDz2Jmg1bTVchX9xduN0rrmRznQ== X-Google-Smtp-Source: AGHT+IFINZ8RYKV8rUEcCkP82iAD5yOfN/QLX5ecmImdhqK8CPCz1Jgle0iGvVw8/+T7qOUD2TEqMg== X-Received: by 2002:a17:90b:4007:b0:290:c6bb:4c59 with SMTP id ie7-20020a17090b400700b00290c6bb4c59mr436412pjb.40.1705956487910; Mon, 22 Jan 2024 12:48:07 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id sb12-20020a17090b50cc00b0028cef2025ddsm10257875pjb.15.2024.01.22.12.48.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 12:48:07 -0800 (PST) Date: Mon, 22 Jan 2024 12:48:06 -0800 From: Kees Cook To: "Eric W. Biederman" Cc: Jan Bujak , linux-mm@kvack.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: Recent-ish changes in binfmt_elf made my program segfault Message-ID: <202401221226.DAFA58B78@keescook> References: <874jf5co8g.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874jf5co8g.fsf@email.froward.int.ebiederm.org> X-Rspamd-Queue-Id: 296A440012 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: uc45w1ky81aukbt3dzqabuwx9g1zc6un X-HE-Tag: 1705956488-754271 X-HE-Meta: U2FsdGVkX1/W+w2Ok5eR0lsYTiMjCMnLjF6FQQAsSG/OXAnUMFr6IkpA/Kwebn8ztF0C1sEjMh6UK3z4uILh9FFoTlJ9T2/35Rgxc0KW7QvLL25sZM7LnKuC1OwrqLDbZEqeP8D9fjNYY1TBwewy2QYo42WTf1Q/aADNJ7VP5+T3hyQAYcGQpH1t+WphbT6h8feZiwMu9ZMQnt1ye+V4pcOQOVMjBCrO/nSn3PAF/Qhhc6ty6gcOHksKk8i2oj9NjyuOI/DBQR6pocoazYX77kOpF1pqn2qddMkl1P6erH2EwoiNY5PrMD94bObS/CPgHYLmq0mhXBMu5lB/qJkl9gPFgoDoyqYDPGy9b5wP3yIu6n62AMOfQfIy9YqsSuSudcFxHeYFryqHZVpxv+bgujq6dsk1uQSGi2AK1yOiRp/RbPbUqyF7weN+Yy7FZirGQtLHzs1kznv+KKUENqbjr0naIqF48JhQnp50Mk4pHllKaAEZ9qJuiykj0P5387GAPGl4ClEp34rns84k/DQF/BcWRLBexW0MSgrJ80eJqk7KeN9gjsStaKrO2HQ9nU0Goy9xWpJE/tjjPtsOVbcLeJiRJQXsW7s2dq4NJ4yYCFo3ByG04pTH4BfnJzho7RS3FdbTMyzP5E3puXZt4Gs0OLVIj8qPdMSMuicY4DSYCOmYcGDDKncPoTf1jijROTim7i7rHsCiVzoobcd8whIlQR4ufr2e5pv9gwnggXHTZAvZkXsz8HAvJR/0ALuKv8mPu25Q6vPefc0cX9QQt5xotzbs2m8+Op3D5HXmKwseURf541uLQEcah9Y2huCF+Held6ugnsjHl0RwK41FraHsiinQPe/sNmoNRyAaxZC9OJFijbBJEguHqB84a5gxIR164lg3/yFNl9vJ3dapgfKnrxnNQr9cs5rmOuGh2K8xD6NOJRmU30o5TzoxrwIKzLnkZvi6FfVDvmsERc/gDbI +sOs6+Mt P3lg8YruTSVs7d3udiW6CHdDpZstVpw6d4y8kEYiiIuo7o3G+hTNfJeEH6f3XJ/vhyZUPW9eAIQcpG7CF5vPNW5yBSMk36oVpsvs6TvJ7VC0trPtxUMVXZOYQ2K4xy8mMTrgHq93jIjxArAjzuAzFbzwE42WhaIkHYzOS5VdsYhPehvgTwbpPasWcEGp1cNObYrZQTprSypiN0xUkMrsaiTRhx76gsiIqmjNTy9gavJV7GWiYLLIEBlkJhg1vYNFajEL3dXLAKe3ZIW80mSbDQ/FYcA6DDwkpQEqLqaWhicaUcKcswxsnhyOR/WOrVBgFoFbxSlqAldEsjn6R4QNymVgsP23WmXtQ7bA50IcVhHMlQW3PS0AAaZji/obm7IUoc5JahiUAc1L3STjOIm7HQnfA5auFCiuXabsfHQ7KtEzkfAASX5XoOXtYoJb1btIbOGQT2MdkxX/mCcM4D/2T+ZiEnjgh705fbgNM 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 Mon, Jan 22, 2024 at 10:43:59AM -0600, Eric W. Biederman wrote: > 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 headers; > > consider the following program headers (from 'readelf' of my reproduction): > > > > Program Headers: > >   Type  Offset   VirtAddr  PhysAddr  FileSiz  MemSiz   Flg Align > >   LOAD  0x001000 0x10000   0x10000   0x000010 0x000010 R   0x1000 > >   LOAD  0x002000 0x11000   0x11000   0x000010 0x000010 RW  0x1000 > >   LOAD  0x002010 0x11010   0x11010   0x000000 0x000004 RW  0x1000 > >   LOAD  0x003000 0x12000   0x12000   0x0000d2 0x0000d2 R E 0x1000 > >   LOAD  0x004000 0x20000   0x20000   0x000004 0x000004 RW  0x1000 > > > > Old kernels load this ELF file in the following way ('/proc/self/maps'): > > > > 00010000-00011000 r--p 00001000 00:02 131  ./bug-reproduction > > 00011000-00012000 rw-p 00002000 00:02 131  ./bug-reproduction > > 00012000-00013000 r-xp 00003000 00:02 131  ./bug-reproduction > > 00020000-00021000 rw-p 00004000 00:02 131  ./bug-reproduction > > > > And new kernels do it like this: > > > > 00010000-00011000 r--p 00001000 00:02 131  ./bug-reproduction > > 00011000-00012000 rw-p 00000000 00:00 0 > > 00012000-00013000 r-xp 00003000 00:02 131  ./bug-reproduction > > 00020000-00021000 rw-p 00004000 00:02 131  ./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:   Thu Sep 28 20:24:29 2023 -0700 > > > >     binfmt_elf: Support segments with 0 filesz and misaligned 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. It's the "if one has already been mapped" part which might become expensive... -- Kees Cook