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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ABB9AC433F5 for ; Fri, 15 Oct 2021 17:45:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2E268611C1 for ; Fri, 15 Oct 2021 17:45:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2E268611C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 65868900002; Fri, 15 Oct 2021 13:45:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 606DD6B0072; Fri, 15 Oct 2021 13:45:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CF2C900002; Fri, 15 Oct 2021 13:45:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 3DC326B0071 for ; Fri, 15 Oct 2021 13:45:10 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id F06408249980 for ; Fri, 15 Oct 2021 17:45:09 +0000 (UTC) X-FDA: 78699397938.09.C55CB2D Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by imf03.hostedemail.com (Postfix) with ESMTP id A670E30000AC for ; Fri, 15 Oct 2021 17:45:08 +0000 (UTC) Received: by mail-pg1-f175.google.com with SMTP id e7so9250390pgk.2 for ; Fri, 15 Oct 2021 10:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=l4qlclu2RIa4oxKpd1H+1z1yST7CZssZbBES01bC8pU=; b=cAOAcqa2nvyIYH0EqUubHMzpXLPqTCLfz9xXXZUr73uY/T9PXlYXrzSWM4agbNawT6 UHxCgHfYfzOnRHuIvx9WP0OnZ8mbvAgQLzUM9uzvOQ9Fip6iBQ8ox7zgwXjDH2XjEKcN oWT/v3c7Vz8AVenh97wnyrnm+5OkVdfp4L2FE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=l4qlclu2RIa4oxKpd1H+1z1yST7CZssZbBES01bC8pU=; b=RLqi3nPP/YCG/Uq059TCc4iRtEN7v7xhSiznmucTjUNNrfLgeYtGwp0nlGDcvd3keL YxBjFo0WzCp6wTwo9h9p/1aVbn5SQyD1xbRdvd56480ltQ6C9cEhB7MOZmsKsyn5dp0A v59K6RR74vTX3xR5sBryo/42qz5RQNYLQ+H8XFXC0SECBfUyl642OIQr9dAY9FLxn2po Hy24rxcNopIXyiVVKk1N/K1oWaMSEOggR8IWJWD1V8W67C1AIoz9a9Sh1MUdIP5eeTL+ R+ztmP1QZZujlkNyRQBtP3Ng2TtRpcdvdm3Lvfnl45ss0kmUHh7oqvR8pibLsmUf0KcM xMgQ== X-Gm-Message-State: AOAM532aFD//b9ic97bKOkmUoiMsvQKjFh/bqiYZlCilhndX2tkHoIRu DoYpqmor+E4dwRigAR07Bx8GYg== X-Google-Smtp-Source: ABdhPJwjRvl42xTYzqW8RUTxPJkRo3VNvT2r9xBa4I1xgxZ5olUh/8U0oh2VG71cExredtCSHa+qkw== X-Received: by 2002:a05:6a00:731:b0:44c:7c1b:fe6a with SMTP id 17-20020a056a00073100b0044c7c1bfe6amr12970406pfm.44.1634319908311; Fri, 15 Oct 2021 10:45:08 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id s14sm5644591pfg.50.2021.10.15.10.45.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Oct 2021 10:45:07 -0700 (PDT) Date: Fri, 15 Oct 2021 10:45:06 -0700 From: Kees Cook To: Suren Baghdasaryan Cc: David Hildenbrand , Michal Hocko , Pavel Machek , Rasmus Villemoes , John Hubbard , Andrew Morton , Colin Cross , Sumit Semwal , Dave Hansen , Matthew Wilcox , "Kirill A . Shutemov" , Vlastimil Babka , Johannes Weiner , Jonathan Corbet , Al Viro , Randy Dunlap , Kalesh Singh , Peter Xu , rppt@kernel.org, Peter Zijlstra , Catalin Marinas , vincenzo.frascino@arm.com, Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , Axel Rasmussen , Andrea Arcangeli , Jann Horn , apopple@nvidia.com, Yu Zhao , Will Deacon , fenghua.yu@intel.com, thunder.leizhen@huawei.com, Hugh Dickins , feng.tang@intel.com, Jason Gunthorpe , Roman Gushchin , Thomas Gleixner , krisman@collabora.com, Chris Hyser , Peter Collingbourne , "Eric W. Biederman" , Jens Axboe , legion@kernel.org, Rolf Eike Beer , Cyrill Gorcunov , Muchun Song , Viresh Kumar , Thomas Cedeno , sashal@kernel.org, cxfcosmos@gmail.com, LKML , linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm , kernel-team Subject: Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting Message-ID: <202110151002.059B2EAF@keescook> References: <202110071111.DF87B4EE3@keescook> <202110081344.FE6A7A82@keescook> <26f9db1e-69e9-1a54-6d49-45c0c180067c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=cAOAcqa2; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf03.hostedemail.com: domain of keescook@chromium.org designates 209.85.215.175 as permitted sender) smtp.mailfrom=keescook@chromium.org X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: A670E30000AC X-Stat-Signature: cj5o14nt3naqsj31k85x6cpbzt3kr57h X-HE-Tag: 1634319908-269185 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: On Fri, Oct 15, 2021 at 09:30:09AM -0700, Suren Baghdasaryan wrote: > On Fri, Oct 15, 2021 at 1:04 AM David Hildenbrand wrote: > > > > On 14.10.21 22:16, Suren Baghdasaryan wrote: > > > [...] > > > 3. Leaves an fd exposed, even briefly, which may lead to unexpected > > > flaws (e.g. anything using mmap MAP_SHARED could allow exposures or > > > overwrites). Even MAP_PRIVATE, if an attacker writes into the file > > > after ftruncate() and before mmap(), can cause private memory to be > > > initialized with unexpected data. > > > > I don't quite follow. Can you elaborate what exactly the issue here is? > > We use a temporary fd, yes, but how is that a problem? > > > > Any attacker can just write any random memory memory in the address > > space, so I don't see the issue. > > It feels to me that introducing another handle to the memory region is > a potential attack vector but I'm not a security expert. Maybe Kees > can assess this better? This case is kind of just an extension of "we don't need an fd, we need a name". There is a lot of resulting baggage suddenly added to using anonymous VMA (fork overhead to deal with the fds, etc), but for me, this particular situation above is what really demonstrates the "unexpected side-effects" of trying to swap an anonymous mmap for a memfd: there is now an _external handle_ attached to memory that doesn't pass through any of the existing security boundaries normally associated with process memory (i.e. ptrace). Here's the example race: victim process attacker process (same uid) memfd_create(name, flags); -> /proc/$pid/fd/3 ftruncate(3, size); open("/proc/$victim/fd/3", O_RDWR) -> 3 mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_SHARED, 3, 0); -> addr memset(addr, 0xFF, size); mmap(NULL, size, prot, MAP_PRIVATE, 3, 0); -> addr close(3); surprise, addr[0] != 0x00 And again, yes, we could program defensively, but it's a surprising situation with new corner cases that haven't been present for years of Just Using Anon VMAs. :) I would be worried about other vectors we haven't imagined yet. So, I think between both the overhead of files and the expanded attack surface make memfd unsuited for this use-case. -Kees -- Kees Cook