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 9DB20C4332F for ; Fri, 15 Oct 2021 17:45:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7DD1560F9E for ; Fri, 15 Oct 2021 17:45:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241876AbhJORrS (ORCPT ); Fri, 15 Oct 2021 13:47:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45532 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241692AbhJORrP (ORCPT ); Fri, 15 Oct 2021 13:47:15 -0400 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E934C061765 for ; Fri, 15 Oct 2021 10:45:09 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id i5so600838pla.5 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=HFtAyPQQvEhDX8plMk8VvE6oj7llJguo4wGaYDCIb0OgoUVxZzx1w5upuakSgtyeph 8oOUBEzMGYCy7c6cbHBrDdKUM9C2e2NFDMR3wPh260AfBE/wfpGZf7CrSWPmeveQcloI 9PrvYPvSlSwrMyKayp6qvU4G8dKCOYUORjZ8i7gNMZOGU/8rPtUWD3jbojgUuhFxbXYR 8QyT8fLhRlbTQBae2pSz1DZwT1mURSs0WRYRL9UPhMOv7BaM3R2I33Tyk/qhnwV2wvBL CKd7DYhaMTbM2JFWq+w1bTjjKspeKABhglZLmnPZ8XJ3EglkUvHnmfLnztg6+NhBCOEu 4f1A== X-Gm-Message-State: AOAM530utc3sVhYPJxeI+7NeGOwwTO3k7z6xYS1y3XydNdiISKSZHh5C zHJ3UJ+CVKCLeyGRxeHu2TrQCZIffrApYA== X-Google-Smtp-Source: ABdhPJwczfHIsKA3OnAo5l/WAXOoc8PybHGuDkIsCsJhUrv57TZZ5Jo2Ma/f9bJDxzij/nvjfJ3D2g== X-Received: by 2002:a17:902:bd45:b0:13d:b4d1:eb39 with SMTP id b5-20020a170902bd4500b0013db4d1eb39mr12112518plx.53.1634319908413; 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 y3sm5472581pjg.7.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: Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org 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