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 61361C369DC for ; Tue, 29 Apr 2025 20:43:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65DD46B0082; Tue, 29 Apr 2025 16:43:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60C686B0083; Tue, 29 Apr 2025 16:43:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D46F6B0085; Tue, 29 Apr 2025 16:43:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2DD936B0082 for ; Tue, 29 Apr 2025 16:43:51 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D6F51C835B for ; Tue, 29 Apr 2025 20:43:51 +0000 (UTC) X-FDA: 83388257862.02.6305546 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf06.hostedemail.com (Postfix) with ESMTP id EC37C180005 for ; Tue, 29 Apr 2025 20:43:49 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=feGaJUkB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745959430; 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=LkyLQBwTJJGrpnl1CxZI8tvol6HSznSH55H78Vjrl60=; b=CQRYyzdOZniTJV0fv5ocqGWfWgUMcKQ2NsX3T8YrAHnPlvJOBaXf4OJ0PtzLwUwY6AqiHx zNyNPUGZFHrCRqz+VQoF1081Pes8CIGX2t9bDc+wQ3UsjUQwBnEgZ5H0F9uTL8KRPjMDxl N+fX6KudZnfgrb4ifHjgHuGZwWi1Egw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=feGaJUkB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of jannh@google.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745959430; a=rsa-sha256; cv=none; b=10z5wU9b9N2Ts/oUIjOWaCBc56S/yxo1Z3H3PTJ/1i2547XGKzq8zJNScneCEDGqaaLMzZ PJ+AWcTFOE4Mc5b1COMP3PlLXcJcTEFY430mksYBNPFqsoU9mRMLMwb46GsSzfZQ41wNVc DZVX/IQ6Brz7/WunAeevXE/+e8IMP2s= Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-5dbfc122b82so13093a12.0 for ; Tue, 29 Apr 2025 13:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745959428; x=1746564228; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LkyLQBwTJJGrpnl1CxZI8tvol6HSznSH55H78Vjrl60=; b=feGaJUkBDo9FkXXZAaQVGUHF3DY9vWcPKUoiIO9BJMa2xY5GYsj22+oDBj6RjbLCK3 nJ33cTWxiRPs7vmMAnkvxoev6AKEBJuiCoHSOvWNT9K/WpEPNZq565CYa231JQP2C1Cx H0vc6shDWhqOuwdoqjIK+C8AVHoaqw85uvRmxXbEWe7Gl02ooLTFyrgDBo5/84dE9y8H 1s/xH26qoQFFRjq2HBJgs7XOzD/LDw0DmuF6/0Ger5YHkBkGcOjMlxXEgvBygMPkeSBf JZUKU7tSpgjeCKtflcF1BEm/sv01k4THG9VYjVvkm9nwvFBkg2iSd3GW3NvdhUsac6uT DVhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745959428; x=1746564228; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LkyLQBwTJJGrpnl1CxZI8tvol6HSznSH55H78Vjrl60=; b=KEeQf1OPVZFwuZ22nPq74hBmCYByTqXUchudxLXw+wzaEEoz4Z3yIaWeObqGqtNCrd NIHTMgnjbTKr5IG/A+AixM1cdEqCn9NgL7oINc44UmMI5MRuYszG3VW/4iUYFTWEIUX3 ZntakcEVCPHIg5rqESt0cxTTYCkbMv8D1KVMy1yqfAMIXZZ3I9aH/T4AqRnRxXPjyrdp /JYDvGM74GAtIVegbRoqhFNNko1OiuHqHhWbINwgzHrHilsBtb+cqUoC9OlyjbYy1ufV FMTOx0U37W12SrY7ki0jIr6eVR5kJDl3kNJ1u9Vrp44rRU/mDBk7QgW1MoOcb1xGi6+G 6V1Q== X-Forwarded-Encrypted: i=1; AJvYcCXdhQDTJN1vUGk2va0ntBQcP/mKt1IRKYAUQrcDEg4B2Qz7+8qbWprQO8Pz2hzq8qy9REUDMTNzxQ==@kvack.org X-Gm-Message-State: AOJu0YwWOIVRTzU5bPmPQK/VbIyLMCwXxo34/zrvOXyAY3iVFK4dWqv7 4X3fNrAEpYsNkMeF0FTCMkPOefIRR3TmfC2c0HeN2AtaQQzP9UQJn2ZNMjw+xrpnryXgwQP1cSA CCVL0kaUyYayE7tSqdHTxqAXrIHZ6zfgdQCD3 X-Gm-Gg: ASbGnct1FICvV4i+LddNYZH755NB0c9h9F+JHTHpkY2Tlpf6vCy6k3uVd4mfjXt9KE3 ugP2u6w/a1DSijjrkb684zWYTWHl6tYWK3RQJx+Cmjd4tCtYxP+ewf8Wn5L1kQkhen7fbuaCQqO 5fckNJGQX3rDMohGQDoM4HTDlEQQ/NfzCOUxacGPn+noLks1rtSQ== X-Google-Smtp-Source: AGHT+IEIgZvYUxouglxxEc1B25bVszxW3uDj1Plpsi1Xo6RrFU9lPw27AjHq3/sFGlfsqKdKORoMM5aPYW2Otdj+c1I= X-Received: by 2002:a05:6402:1d21:b0:5f6:c48e:82bf with SMTP id 4fb4d7f45d1cf-5f89409483amr28294a12.0.1745959428013; Tue, 29 Apr 2025 13:43:48 -0700 (PDT) MIME-Version: 1.0 References: <20250418174959.1431962-1-surenb@google.com> <20250418174959.1431962-8-surenb@google.com> In-Reply-To: From: Jann Horn Date: Tue, 29 Apr 2025 22:43:11 +0200 X-Gm-Features: ATxdqUEqqoG4LoIyZ4OwQmz6A4H2tBfAsqh63IM1Om7wtHRV6kYoe8YBb1fcZ7Q Message-ID: Subject: Re: [PATCH v3 7/8] mm/maps: read proc/pid/maps under RCU To: Suren Baghdasaryan , Al Viro , brauner@kernel.org Cc: linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, david@redhat.com, vbabka@suse.cz, peterx@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org, paulmck@kernel.org, shuah@kernel.org, adobriyan@gmail.com, josef@toxicpanda.com, yebin10@huawei.com, linux@weissschuh.net, willy@infradead.org, osalvador@suse.de, andrii@kernel.org, ryan.roberts@arm.com, christophe.leroy@csgroup.eu, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: efoy1wtqg635n8phdt7c143p3zmuupo1 X-Rspamd-Queue-Id: EC37C180005 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1745959429-159059 X-HE-Meta: U2FsdGVkX1/R4CIPOc3LMjrVc5ixwSYJuiWUZ/Nm9Zd+lpMCpQV+LJhcbuOgJi2j5OMjx6KitOp35Fs6IBIvCM4nKarfpxkpPx5qHRAzZTs66rB/wcuvvDo+z99dy55QN9D8qdPb7Ai84PG8rQ9F8r7SY9zrW2KqnfUXp+yaY6trc/yoyIBWXECPTndXKZE+vUDsRxpkj87jbPnAJbPwXRIrL6RwzPDb/FJoWUNIvVBW8Kmn02H9fBkLy8yijcMoiSSYWOZoASbBna6vw21lHPiVFewEKyyg/D5+gOuCDh79F3jb7LsPBy1DbD6T4RFt3b2t9XwYc7GC65mRFzabxUvplpN8i5Xpq4gIbM8OQWCaTsc6bJETyoJvSauYGqqu2ArcHJ7NZhLYWQJELBf3gKdjddtULXNPtUq+TxdHhLXGNncdA2xgVJlrktl2IJSiEDJxlkN7GQLeRM+DR/oD+dv5JNsD7Ax8JF77u4+446SAIY4feDYnB2WM+GQjyLbXwHi6EipeBLY8cymTIxIQOFOnuBN9AgQodkHq1F6m9eZ8OcLncTsy5iMEuGsXZPEs41ty9PaMbooJ8X5oHlpzjyhmiWoj2Uv+WsVRpZgEE0viZ1Hx4gt+R2lTCU2EQAq85oyt7you39TCtAIovklC59OhnYH23/YMFAhKNFODPzPEMhOQJXqqOqVm0yuNkPG6EOP5tvbBrw0K1JIWXNHGk6TtoN2QG/m9eJiicVj/lhgxU9NP3NDPwEBIQ0GUtqqiiuZVCCkFyMKd8D3W5DEFFZ7o0aGEidOJJ9OmW13mcn561XOIE6Cn762MNtZ+T0BM15znyG3XfPxqqsGTOLSz6yb3qu8/M0azCWmhUIUuyNx0U6QPi/QXqpXSUre2cpK3Wl8QBCqEqRCQizFOLmRwhdyVLHz9z8ZbF3lsCqw5dRoodICyhGmHasyhTpKeLwcwTgMCBaCadQvHo4Qo3p7 hojeJDWX rw7W4yPk1pnt6aUeX3q8iSAhEvKF7S42FPbERrdWfnsyNJQW6qIdlFpgKGkZUlX6F88ncSNPOSZyXR6IxwS6o+t1Kxg0FaObMiexubt9m2sWIrjt3z00U74xzIgylTl8LpTz6/YvbVUuItvBPlaKvtVXV53mZ3LKztuo/qt+/v6zBPEpYjV8GVv2vcd3FPdcj35E1odB9f+htBx5TjymOFLVhzgHsX7J3aIuq 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 Tue, Apr 29, 2025 at 10:33=E2=80=AFPM Suren Baghdasaryan wrote: > On Tue, Apr 29, 2025 at 11:55=E2=80=AFAM Jann Horn wro= te: > > On Tue, Apr 29, 2025 at 8:04=E2=80=AFPM Suren Baghdasaryan wrote: > > > On Tue, Apr 29, 2025 at 10:21=E2=80=AFAM Jann Horn = wrote: > > > > > > > > Hi! > > > > > > > > (I just noticed that I incorrectly assumed that VMAs use kfree_rcu > > > > (not SLAB_TYPESAFE_BY_RCU) when I wrote my review of this, somehow = I > > > > forgot all about that...) > > > > > > Does this fact affect your previous comments? Just want to make sure > > > I'm not missing something... > > > > When I suggested using "WRITE_ONCE(vma->vm_file, NULL)" when tearing > > down a VMA, and using get_file_rcu() for the lockless lookup, I did > > not realize that you could actually also race with all the other > > places that set ->vm_file, like __mmap_new_file_vma() and so on; and I > > did not think about whether any of those code paths might leave a VMA > > with a dangling ->vm_file pointer. > > So, let me summarize my understanding and see if it's correct. > > If we copy the original vma, ensure that it hasn't changed while we > were copying (with mmap_lock_speculate_retry()) and then use > get_file_rcu(©->vm_file) I think we are guaranteed no UAF because > we are in RCU read section. At this point the only issue is that > copy->vm_file might have lost its last refcount and get_file_rcu() > would enter an infinite loop. Yeah. (Using get_file_active() would avoid that.) > So, to avoid that we have to use the > original vma when calling get_file_rcu() Sorry - I originally said that, but I didn't think about SLAB_TYPESAFE_BY_RCU when I had that in mind. > but then we should also > ensure that vma itself does not change from under us due to > SLAB_TYPESAFE_BY_RCU used for vm_area_struct cache. If it does change > from under us we might end up accessing an invalid address if > vma->vm_file is being modified concurrently. Yeah, I think in theory we would have data races, since the file* reads in get_file_rcu() could race with all the (plain) ->vm_file pointer stores. So I guess it might actually be safer to use the copied VMA's ->vm_file for this, with get_file_active(). Though that would be abusing get_file_active() quite a bit, so brauner@ should probably look over this early and see whether he thinks that's acceptable... > > I guess maybe that means you really do need to do the lookup from the > > copied data, as you did in your patch; and that might require calling > > get_file_active() on the copied ->vm_file pointer (instead of > > get_file_rcu()), even though I think that is not really how > > get_file_active() is supposed to be used (it's supposed to be used > > when you know the original file hasn't been freed yet). Really what > > you'd want for that is basically a raw __get_file_rcu(), but that is > > static and I think Christian wouldn't want to expose more of these > > internals outside VFS... > > (In that case, all the stuff below about get_file_rcu() would be moot.) > > > > Or you could pepper WRITE_ONCE() over all the places that write > > ->vm_file, and ensure that ->vm_file is always NULLed before its > > reference is dropped... but that seems a bit more ugly to me. > > Ugh, yes. We either ensure no vma->vm_file tearing or use > __get_file_rcu() on a copy of the vma. Or we have to stabilize the vma > by locking it... Let me think about all these options. Thanks!