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 1BB33C46CD2 for ; Mon, 22 Jan 2024 22:12:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2C608D0002; Mon, 22 Jan 2024 17:12:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DC198D0001; Mon, 22 Jan 2024 17:12:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A3688D0002; Mon, 22 Jan 2024 17:12:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7B64D8D0001 for ; Mon, 22 Jan 2024 17:12:22 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 445291C1308 for ; Mon, 22 Jan 2024 22:12:22 +0000 (UTC) X-FDA: 81708346524.03.67BA1A1 Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by imf13.hostedemail.com (Postfix) with ESMTP id 7A91220002 for ; Mon, 22 Jan 2024 22:12:19 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Bg3iWCML; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of keescook@chromium.org designates 209.85.160.41 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=1705961539; 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=jgKcLWWKTY3O1sDjk0J47fn3O87zVjpZotecCA+zO1Y=; b=JLoLHnCxWgsq6BfhFlKIrVjSZ2TD7gg21ft/YBhlydES0ZpM9fhyHTQw5hD0WdNW0YmFhW qSiyCWe7mi6NI/84QH+3bIgVDrsHQnoV3ZUshtQBJkAKkYBvuirJTp0ztPAeeO/TFn5k60 Cho/icUQFPPyFCIF2HaO7oL0WjX3uUU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Bg3iWCML; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf13.hostedemail.com: domain of keescook@chromium.org designates 209.85.160.41 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705961539; a=rsa-sha256; cv=none; b=K+5iAw1MBe03LMMkgl5CfHnBz/dBe8ZQYqOjOzaQc5HIMwUMJIeooRfndFxfhXQ/bJBapw p1MPkwOMr3Fy4hBkTVuNhyvwJsVbi1NoFZRFBcsyWLo/RAk+y33P5LOzUiRZ2rvGLBDllI /hb4TOyz0zDaXwR8il0DVR+pri96XHI= Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-21486144069so15581fac.3 for ; Mon, 22 Jan 2024 14:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705961538; x=1706566338; 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=jgKcLWWKTY3O1sDjk0J47fn3O87zVjpZotecCA+zO1Y=; b=Bg3iWCML4W+gFs7KHYZ0jX27ozRBuANwjUusA1w9/hTYdmkbpmdCjo5v8ce+onk/0l m9miJ7TmEfM9XURb2laUB8sDRyV/bTl5v2tfgnkTuTiHm5TY02kMlCiptMXLYGQr7uOB hiuWhIx9G6XdTnYRDIecNuRHN5iqeo8uI+dSo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705961538; x=1706566338; 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=jgKcLWWKTY3O1sDjk0J47fn3O87zVjpZotecCA+zO1Y=; b=XQeE1DptGTiA2bts2p4tp0yxAZI0avmUr9+kRb1Du2H1qK8n26Cr5aqFwde+cGkOv4 Ua0NF8q/jpMsIEgjaATSV2oxfdSD/MbDd0lcfSPaPio2p+eHXCMC9niK0O3LlZTvHuA/ 25x343M95A69D0DAl++mLsD9445qV7PggxTTgR3ylg8TirCdkDXZ3jnoSYkeWsIvAl3c lWGPFkG2Yycb2UGvoBLJFWhUSQMTmXuYZqoGASAXGOGOSQdfWm8WFSDBeV3xPkppTedX MILNGxsRlFTYl4nxYnu0sCmYCHfDhEMfL4TJvhmSMy2VdoaPD7EwxrPOCVJEoTNTJxv3 XqPw== X-Gm-Message-State: AOJu0YzHi/KXzkAVYcCIb0hfQem85G4aoZFh6Tu8NsCrI/F1zYIk3Gda Nw97Ae4TOmCL6zJ44vrBhglR5D51cP85gyMeqdrnK99hsexOZkpjOlLrjkxHCQ== X-Google-Smtp-Source: AGHT+IEWjlQw+cSPVMJjT7U5wLtADDdKcUw+JASJ25omFvYBlW8fm+b/W7oPlH2U07JZhfioUWKK1w== X-Received: by 2002:a05:6870:5704:b0:210:b61d:7b81 with SMTP id k4-20020a056870570400b00210b61d7b81mr621218oap.38.1705961538623; Mon, 22 Jan 2024 14:12:18 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id i191-20020a6387c8000000b005ced88aa031sm8852613pge.48.2024.01.22.14.12.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 14:12:18 -0800 (PST) Date: Mon, 22 Jan 2024 14:12:17 -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: <202401221339.85DBD3931@keescook> References: <874jf5co8g.fsf@email.froward.int.ebiederm.org> <202401221226.DAFA58B78@keescook> <87v87laxrh.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: <87v87laxrh.fsf@email.froward.int.ebiederm.org> X-Rspamd-Queue-Id: 7A91220002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 9ohh5wouzata514e4qy88s5cd4zzro3z X-HE-Tag: 1705961539-943864 X-HE-Meta: U2FsdGVkX18aWw5FivuphpiYbbYlCXYZvYO7RhWHDvTLphz30buwOPoSxV3E/nLI5FctJ6aRB9zvWam/9HLQX6Tp7ExvtipnMTRjI1UtfMWSOo7OCHc4lr63fIrXNYXgSg9Q74oMkM/qhMyuAzPJOnyJnbR0U2wM70mO2SzeU80VhxoDC/aH1zFPXEmaJhymXkpa08YTuZB/+laFLGJN+tx8hsE9aN7cd6yuiDV3zYlOrVwTK1GoMUASNolBQpr/XLpqb9+9+bKyp+Tiit164mnYG1GPvTJAOjjxmXQ95wSdZsVwd+cIn+560uqNnSB7LsglEkwQlVus3/KJf+9PsQ+UyUrxTfjWe1tdLL0SSQXqpaufW6ds1WKSUGCSkMZhRw1+GinxAIrflRwFHLMr77r5+vsTChsToj/DAjGeaOx6BkXPvzU4lwSFDXFTqPkdf8Q9CL3HWrL2ZxD8kNdO/vVbBWh3qzq2lPW46v4Gq6RWJiLT6RLBwfM83I/9zGQwKsee13XgE7ESVX69zx+sLke5fP9U5fOtwZjrstXZdEwpIEy7TbsX3lAHkYP5JMb4vdY9OsGnxJss11xCNkkN0EqNHr/Fve1ZtVYbrRgW9NRdXz7S2O0s+Jjoha4IZsRKfU1f9xUazHZiV/cm0t0ypRecgPX/RxNzCsZbXfbrX5nn04aj+SeGk97vuhayrzTBDEWpvyOdLPqhDLSaHy09uLElW7vAeMf4Ja8YBGHC9WDSIRXX9CH/xy5fQX7dCA8OBWFtx8foMNTbE09F6LJ5cNOCYKUyTMOAUToZHTESwc4ZY8Sq/VwdL9a/oHEENCtR2jrD8GSdZ//fABgzY2rJZt9rU3AzQDBvMA2ec1pGRXhGnuAiP5PTMLMx/tOLPtYGktHHtlZpzwNLgfmEoqrgFmF+PJcN471ZMr+5h2r3dxAmno4wv0Iuo6RtybiUO52Chg8nlpFNDd84sLYTGt5 RYby/2Gj RLcJKFFOQlcDSKJlPPB6dReikaQ5WfD+oqRFRCKYo1Q3oqam8MpNWkPw4idrH+foFV57IJWYE+kESMeWTERFeZ4TEXNRWuBpzY1hSgGMdIWLstvBN8zAbt9fh2GNBZcQTfMqYsKC9NO9+g2LjRdFINgKr9zBk8AnxgAOwsd1tHgGkjZEEyK/tZ5RhmgG4eMQv3PKfi/Y/6ZTNTJ9EgTcbu0eKoiZml7uw7b/pU5Mtx629jvlM458BUGrvrOGt9ACb09E6zQqcJXvPwOE+CDRJ+q+UetO39XHvnc81xL+7Vm6GbxrIXR0lhhKazc/48y2TEQA55c7nbYu2wKahoNjhYAvHsUy8HOPCbCqwhgZhArELgDg+odB5K3LdfSjvEmFFJDmbB+R+Xx1mN6gZAfRAMwogDY16Wb//JOt1ohO9V0C4l2gjopKBKekU4+/rb3uf54fy97OaTPg+txiFZQ7ThUlsMqA6uUtVDa0eM49i40XsIZ1txIaNtlpGHDDY6m9thuk0iiDtRCITQ/IRqDQc4GN6JZq+ptY2tdQU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, 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 03:01:06PM -0600, Eric W. Biederman wrote: > Kees Cook writes: > > > 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... > > I am wondering if perhaps we can add MAP_FIXED_NOREPLACE and take > some appropriate action if there is already a mapping there. Yeah, in the general case we had to back out MAP_FIXED_NOREPLACE usage for individual LOADs because there were so many cases of overlapping LOADs. :( Currently it's only used during the initial mapping (when "total_size" is set), to avoid colliding with the stack. But, as you suggest, if we only use it for filesz==0, it could work. > Such as printing a warning and skipping the action entirely for > a pure bss segment. That would essentially replicate the previous > behavior. Instead of failing, perhaps we just fallback to not using MAP_FIXED_NOREPLACE and do the memset? (And maybe pr_warn_once?) > At a minimum adding MAP_FIXED_NOREPLACE should allow us to > deterministically detect and warn about problems, making it easier > for people to understand why their binary won't run. Yeah, it seems like it's the vm_brk_flags() that is clobber the mapping, so we have to skip that for the MAP_FIXED_NOREPLACE fails on a filesz==0 case? -- Kees Cook