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 11CE5C5B543 for ; Thu, 5 Jun 2025 21:12:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C71B6B00DF; Thu, 5 Jun 2025 17:12:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 975A56B00E1; Thu, 5 Jun 2025 17:12:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83D476B00E2; Thu, 5 Jun 2025 17:12:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 657586B00DF for ; Thu, 5 Jun 2025 17:12:09 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1BB68161683 for ; Thu, 5 Jun 2025 21:12:09 +0000 (UTC) X-FDA: 83522594778.10.CA32A5C Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) by imf30.hostedemail.com (Postfix) with ESMTP id B766180002 for ; Thu, 5 Jun 2025 21:12:06 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=u7Zb2tJH; spf=pass (imf30.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.139.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu; dmarc=pass (policy=none) header.from=columbia.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749157926; 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=Kush5qwyq9/DqRN+b1m8jN+XUrL2KXoC8QLXMDNE4wU=; b=IBPe3KDIW9Rcg4d8smQ7qAkpg7QYZNxxODmaCljx+VgiO3ID3zoEAzq9W9jOQgU0UtDFtL 2qMnJCgvYttaJ+2FnFV3RPbt4VeN/BAQWDP6v4xKNVVHSCb1y+0Mk9i438dat6rjkYbx9P 2bg/DJFfRUofsaDkX45Zh+w0fZC2Jj8= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=u7Zb2tJH; spf=pass (imf30.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.139.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu; dmarc=pass (policy=none) header.from=columbia.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749157926; a=rsa-sha256; cv=none; b=VNgVJ7gFY7vSOEn/cn5pELsZbj4/OZBLz0ctdEuAISEQFyLhWvHAKAUvyjcBrdzJKg+Tm9 AYYU2k1JdikQlS45Ts8lALjtKLOyRYro7JA27PsuZhCRBdqy2JepXaavC+L/ufp2JSK6QR gPIIvLoWtr+yP9rCs5rV9QLWG9VUWHc= Received: from pps.filterd (m0167074.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 555L4fSW020698 for ; Thu, 5 Jun 2025 17:12:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=cc : content-transfer-encoding : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=pps01; bh=Kush5qwyq9/DqRN+b1m8jN+XUrL2KXoC8QLXMDNE4wU=; b=u7Zb2tJHdwTWrw7lpbKds/xt7Ei0B3C3pjxluA4tCdj2klqhfEqXfphJPtOmNpniGDSm yTWk8eExyo6xnS7CVppsVtSoWfZvuWKcDFVGWHxaG94vdKKXG4NeIMUMLWmx9R0xKsmW /3qeeHtzVauQFcuwVw/viETMVeKcs2pRm7StYauVtOXjbd4bCp4yP4d1CZw3gjDqjZal GUTHKxZEWITolJ5ss57kuU+RLHCNgR4NIVnZFCRLVwsITLD4wnlGbThmoiL32j2ZWt5X YlriJmFTuowwMIqvq2/j8iAJ5GA6SRXCGMCMqzjR3rBP5oT1dvxTSlEakXZtlJZmBgn0 gA== Received: from mail-yb1-f198.google.com (mail-yb1-f198.google.com [209.85.219.198]) by mx0b-00364e01.pphosted.com (PPS) with ESMTPS id 472ycqr879-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jun 2025 17:12:05 -0400 Received: by mail-yb1-f198.google.com with SMTP id 3f1490d57ef6-e707377b3bbso2003869276.3 for ; Thu, 05 Jun 2025 14:12:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749157925; x=1749762725; 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=Kush5qwyq9/DqRN+b1m8jN+XUrL2KXoC8QLXMDNE4wU=; b=rW4t03S0Nzia67i2XJTYNc3EVJ7D0+AIoct6voZqtIsod4NzPnDlCVZHpSS1eKdm1Q 5d7EGVbTqvqT+VyljSOfi42aveqJPZBERffIuqIbsvVvFjQeof15WOx2ry6heZQlRyQt juTYhqCmpXNKOzMG4ne/zxXgyzmDa1wzxMZmpufUqNnXJPKAH9cEfrEJHO6LbPXAjKSx zpFSCh3L/B1InuoJ9nDtZN+MCi1hru7Iv6lJr17nwkgA7UOd/XGyAISJIf0jbht4h5m5 pDZJJWGlTKaOETOd5RZuZUGEzIEQTxZjsC7O0f+q3hMYbh+dL0xiupnW5nJfz0zHNooO mIyg== X-Forwarded-Encrypted: i=1; AJvYcCWzVaG4L899/0xkVcVPDLw8hPbc62UliDssfCcfy/Pd2Vj3Fr5UM9BF1pEVLQKd0MOW963+Gp5QNA==@kvack.org X-Gm-Message-State: AOJu0YwF3ccBOtSMgOD9o2Qa1Jk33t2U5EIw9LKsEGUnr1h/y8iYw79H QfeN0yvjouLEaOusctH6b3g7eaJlhUv97qcnwkmOjwKsVkHcz+8J9Blz8JtS4n8MBUUBVcnw52O lr0rFrRkHAR0SS74mdMR2HNic/C76OT5WCpmbZBUy3Ud1ILXPrVzl1gnlkMAx7/5tc3vLOXmsAt D0uMhAStUt/Wwourt/qFxNNvU= X-Gm-Gg: ASbGncv7LWN0OJOGt7UQXd6CnUkmswfEZqK6QYIDx3BzECvfT50rX5KugeRL8SQdOs6 g8u/Pw1FFqJ8SRDatgL08V5D1BJZdJhF6KnVCn3edySOsaKGyJDDEbgwkRbkcE73tg4iCww== X-Received: by 2002:a05:6902:1889:b0:e7f:6edc:9a3f with SMTP id 3f1490d57ef6-e81a2546617mr1663377276.38.1749157924963; Thu, 05 Jun 2025 14:12:04 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHG8hbIKU02qfpnzheLHwAIRLhIadezcTaFiXw/C6Jl6lhZS+eyurv6XraXAjePAIr+pl3aGIG62PRNxJdNgig= X-Received: by 2002:a05:6902:1889:b0:e7f:6edc:9a3f with SMTP id 3f1490d57ef6-e81a2546617mr1663348276.38.1749157924576; Thu, 05 Jun 2025 14:12:04 -0700 (PDT) MIME-Version: 1.0 References: <20250603-uffd-fixes-v1-0-9c638c73f047@columbia.edu> <20250603-uffd-fixes-v1-2-9c638c73f047@columbia.edu> <84cf5418-42e9-4ec5-bd87-17ba91995c47@redhat.com> In-Reply-To: From: Tal Zussman Date: Thu, 5 Jun 2025 17:11:53 -0400 X-Gm-Features: AX0GCFtlF25ewvTNublXIrjrXRtQHMeIQW9tEnZzcZQU9P8wEJHvMPcfMh1lDXs Message-ID: Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd To: Peter Xu Cc: David Hildenbrand , Andrew Morton , "Jason A. Donenfeld" , Alexander Viro , Christian Brauner , Jan Kara , Andrea Arcangeli , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Proofpoint-ORIG-GUID: gDmut7VES9hREs83zKWkm9HvkryZMrhT X-Proofpoint-GUID: gDmut7VES9hREs83zKWkm9HvkryZMrhT X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjA1MDE5MSBTYWx0ZWRfX0426lLHRnQyo QuzcfE0GmprOwm6YfnDutTowEfAzoqDA3DD34gpl9uDcJVc4PG3ETratrxgHUd1r5ynPlaxMEUq AJc5WzJvL9YiOr520KfMWhozgZMKGxebpg8NIpogSDTOxmHGev3HRNJ0UElKX7rkJ4r8oR+RROy EzNaVCVMXS8nH1Aphb70UQTrLPOXDLsGOSnFM8ikoOXv5pJRe2ft5UduZThiwnWQBfypkR73XNG 6Cg7jFa7y1kUxGHXy8qjkUhm3JA0a8HHa646UwziYaz0Xvel2a0xGJghIKo5gZHMo5u0FVBwK5j 8PVeHHtBRcuNjY+ysI71XAMXbFr9Sbio4BxuUnPmOrcpsnzVbGvn7OQROWKZva0/xMEM/ECyewD 1q8JWNis X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-05_06,2025-06-05_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 phishscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 bulkscore=10 spamscore=0 clxscore=1015 priorityscore=1501 suspectscore=0 lowpriorityscore=10 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506050191 X-Rspam-User: X-Stat-Signature: pwzbe1p6kgcnrhx6n6pjpnozjngnm3re X-Rspamd-Queue-Id: B766180002 X-Rspamd-Server: rspam11 X-HE-Tag: 1749157926-263585 X-HE-Meta: U2FsdGVkX184Iz1UOVo+n7vLJ6vJe3wsBriEGTeB9OxJWefyN9B+Cgpal5VdwbEv+ZdeQTrTns79AUWuPOljuORaav7Tzgxqi+HduS3SmKX3fomzov40CpWUrN7SqN+MUHJUjNVOjnDudwWusqyCqwVbmH2kIa2/wmVpoGjPDXV12m2fanpbuvczs401HsqPMAERMKn3DD6+SKlLAKzf4c7Fy9h6fCj65GDdMQIqdLMif5mBqTRX+a/Y37XXGUJqKrhEBdzKbGH/72otIEcW8hGvV/PbWHYkHQyMLSR3dAPS60oRPPdJ6zZgLknsXU6RpAYIhQamJ9EGJx0Oyd64IWmhslLVXnvDQNQVMQCuPMjpUPoBZ8fTvCfOi6vKn9c7xZCHIO6aiYLyDX3DCFoUeYFamy2c1Gkw3YoOsbLIkrd3DC4nKTmD2amIll0s4C89pp9YWsWkEJvoxh1ENz42Vc7eggYJzwXvquvymLbv6dohi8yOzYy+qLxNg850s0+P/nNyNfBRQsblhfAgwdoJkR69/TN35eApb0+7CfcrmtnSrkCk5Oxf5Ak3Xg4phe33nq7x8m6HZL+py5ujdpcV3W/wzBZSiN7vuChFNSxOasjUwdY6qV9DSTwjQPYqh0HNIr4ECUBSoPAhQ01tw8xdDmMnQ/bVVOcIld0qJWVuYpGMHQq1BIaNDeZU6HFDaNXV8ozsEpUQ3sp5uqoZmo+V8V7VIWmsqsIKmcM3YyWzFdO+3getHRHWNSpNzXcHzlUZ4zR+QnmdQ21tt3Jh6CEaTBpAbDbOhSW4KPXY+3jZfO0z1knpYrX9CLhsXgC3u/wtmfOXMEQE8IrJjnjNvdgjlf9FVXCRM8qHomzQ9RaVTs3mxeSXSA5ScqaGF8Fs1E33yBLz+OoQx+IC8727r71teAsO5NEtbdy+QSsPe8VEV2JNjWNqP/4YAj8tjUso/5x61BvbjfcEqt2kbs50ub3 56oOUTgM /jHZKuT56kTpYxjEE+WEkMMEyH6/bT4l/q9dMVTSVtpAsd7orEkfPcecGVN9xgJRsUnfgO5S4Idmp/t0RUvYTn2KgVfeJy50K0bMZj/dxleVyKjWTO74xxOBvpFQu5I3s7DB1sGEFA8mMHxvhdMS5LzgdbhBbT3cmU4vghx/tfB3Oxl6EVl/R0/EfedOTK5ljtARVOgzbBGlhw6w8ISY0IcD362ajdMK8d1QubHhv79cFBz5HgHPpp5r0gGm/G7s90kPQ10nXnsddQtrqOpvqM0lThXKrQTXBk4Cdb1DMv9Ww8mQd5m41JYHW7h22hjDYnpYj 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 Wed, Jun 4, 2025 at 11:10=E2=80=AFAM Peter Xu wrote: > > On Wed, Jun 04, 2025 at 03:23:38PM +0200, David Hildenbrand wrote: > > On 04.06.25 00:14, Tal Zussman wrote: > > > Currently, a VMA registered with a uffd can be unregistered through a > > > different uffd asssociated with the same mm_struct. > > > > > > Change this behavior to be stricter by requiring VMAs to be unregiste= red > > > through the same uffd they were registered with. > > > > > > While at it, correct the comment for the no userfaultfd case. This se= ems > > > to be a copy-paste artifact from the analagous userfaultfd_register() > > > check. > > > > I consider it a BUG that should be fixed. Hoping Peter can share his > > opinion. > > Agree it smells like unintentional, it's just that the man page indeed > didn't mention what would happen if the userfaultfd isn't the one got > registered but only requesting them to be "compatible". > > DESCRIPTION > Unregister a memory address range from userfaultfd. The pages in > the range must be =E2=80=9Ccompatible=E2=80=9D (see UFFDIO_REGISTE= R(2const)). > > So it sounds still possible if we have existing userapp creating multiple > userfaultfds (for example, for scalability reasons on using multiple > queues) to manage its own mm address space, one uffd in charge of a porti= on > of VMAs, then it can randomly take one userfaultfd to do unregistrations. > Such might break. As I mentioned in my response to James, it seems like the existing behavior is broken as well, due to the following in in userfaultfd_unregister(): if (!vma_can_userfault(cur, cur->vm_flags, wp_async)) goto out_unlock; where wp_async is derived from ctx, not cur. Pasting here: This also seems to indicate that the current behavior is broken and may rej= ect unregistering some VMAs incorrectly. For example, a file-backed VMA registe= red with `wp_async` and UFFD_WP cannot be unregistered through a VMA that does = not have `wp_async` set. > > > > > > > > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory = externalization") > > > Signed-off-by: Tal Zussman > > > --- > > > fs/userfaultfd.c | 15 +++++++++++++-- > > > 1 file changed, 13 insertions(+), 2 deletions(-) > > > > > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > > index 22f4bf956ba1..9289e30b24c4 100644 > > > --- a/fs/userfaultfd.c > > > +++ b/fs/userfaultfd.c > > > @@ -1477,6 +1477,16 @@ static int userfaultfd_unregister(struct userf= aultfd_ctx *ctx, > > > if (!vma_can_userfault(cur, cur->vm_flags, wp_async)) > > > goto out_unlock; > > > + /* > > > + * Check that this vma isn't already owned by a different > > > + * userfaultfd. This provides for more strict behavior by > > > + * preventing a VMA registered with a userfaultfd from being > > > + * unregistered through a different userfaultfd. > > > + */ > > > + if (cur->vm_userfaultfd_ctx.ctx && > > > + cur->vm_userfaultfd_ctx.ctx !=3D ctx) > > > + goto out_unlock; > > > > So we allow !cur->vm_userfaultfd_ctx.ctx to allow unregistering when th= ere > > was nothing registered. > > > > A bit weird to set "found =3D true" in that case. Maybe it's fine, just > > raising it ... > > This part should be ok, as found is defined as: > > /* > * Search for not compatible vmas. > */ > found =3D false; > > So it's still compatible VMA even if not registered. > > It's just that I'm not yet sure how this change benefits the kernel > (besides the API can look slightly cleaner). There seems to still have a > low risk of breaking userapps. It could be a matter of whether there can > be any real security concerns. > > If not, maybe we don't need to risk such a change for almost nothing (I > almost never think "API cleaness" a goal when it's put together with > compatilibities). > > Thanks, > > -- > Peter Xu >