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 D0049C5B543 for ; Thu, 5 Jun 2025 21:16:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4506E6B00C7; Thu, 5 Jun 2025 17:16:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FF7D6B00CA; Thu, 5 Jun 2025 17:16:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2C7AB6B00CB; Thu, 5 Jun 2025 17:16:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 0BCE56B00C7 for ; Thu, 5 Jun 2025 17:16:06 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 46986C1624 for ; Thu, 5 Jun 2025 21:16:05 +0000 (UTC) X-FDA: 83522604690.17.FE133A4 Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) by imf21.hostedemail.com (Postfix) with ESMTP id D61521C000F for ; Thu, 5 Jun 2025 21:16:02 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=nlIddnrB; spf=pass (imf21.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.135.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=1749158163; 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=kYNh9HFT2uHBGBuTCKgX10WS8SJF8NGZEUcVRDSxRuQ=; b=HZffIzVhIqdiHm3NFHrjzjRf5V7tza4t3c0qeDubU3XDTWdJtXHJxvAmZmJZIKIeVuG+eo Knz9pcRhcIwlBdsVWOMXkgJ9xxT/da1NECs/62eTbLEaXpPbz5RdD+U3aISZqrL5eYxog5 lrFMyqUoAVC/ACpVKWgZyCu8Bgl1Hog= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=nlIddnrB; spf=pass (imf21.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.135.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=1749158163; a=rsa-sha256; cv=none; b=iUpg/ROr5Jjur3ix+GfxeJWPaze+XXklnLIT05+DDDITtilZhrsAcgiSL1u4kH0+EBqYf+ lxKnDtp35FK1/22UBb4SVwZTyjzHNm+xpwpQdVpL0Q9oAb0MerbfIQCOUU7uKfspwIjGNE eNKV0/0rrMpy0PbYKie3dTHv0alykIY= Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 555L4iqm025142 for ; Thu, 5 Jun 2025 17:16:01 -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=kYNh9HFT2uHBGBuTCKgX10WS8SJF8NGZEUcVRDSxRuQ=; b=nlIddnrBHoiqBQUxB3TXUWD9X49XJOdQ8+6EFQ5EkkzQBJ3Ia4xkx6p3xxL6htuwx2k2 MilhN28kQAe1lMta4lgEf62GFMpuusvSIwB8OX959Du/kJ+7/9/udrZ+bsChklShmuvE R6UQOtySiL0jiZJxeEY+djwK81qUIFPntG2IP2HS3Y+jmPWute/Mc4Kr+ppfCYyQ0ctV fweOOaMHrYGDfqtcfq0Eh/KCeG4NoXFx7TLozSakYOPqBMRwehriUz0O/bdX9vPVsFig UnJ2V+4rnw+qKv6oYuaVKhdQY/eaEHZbO5kt0JyKfAxzbgH7oyDkFEFwxTRogKMnbpcm 8A== Received: from mail-yw1-f198.google.com (mail-yw1-f198.google.com [209.85.128.198]) by mx0a-00364e01.pphosted.com (PPS) with ESMTPS id 46ywy121e9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jun 2025 17:16:01 -0400 Received: by mail-yw1-f198.google.com with SMTP id 00721157ae682-70e7b4e1522so21985657b3.1 for ; Thu, 05 Jun 2025 14:16:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749158160; x=1749762960; 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=kYNh9HFT2uHBGBuTCKgX10WS8SJF8NGZEUcVRDSxRuQ=; b=gEP73OhwXALEgZRJEKcVDdaSaiC28mMJ24g1O9oWwtmfRKvAHjrMvYVSULkuk+c+kt iBlpkv+slnBhtA8m6fNU9jsoUGyrlePZBEBZGak2QiHnxKP4RP8IncP1sBHvBubDPSY3 vkCCZ07ut65yDY2pofHYooyZrbk11JrZLeeVIB8PKfIDh7rqSIJL7stwuD16vEDE+LeY /YVYDZDMGMjCH+2WckmFE1oGqQMszosXzoFJsqFuMezFrLrSZU/2uCd+JW8PLEvWDfwr +9P098GerxY9QYsat5xTyurUEguSt2gC+pcH9O3E3rBX2rmdSDJCEAYyW3TtvpXmg/MR Vi5A== X-Forwarded-Encrypted: i=1; AJvYcCUJ+WEpc/oMbApOVXaeL13uu2qoE/+0RNHYJsyvm6nppCGGIiwWKA4cgdd/uHJuZ6Lp53vxDCGHgQ==@kvack.org X-Gm-Message-State: AOJu0YwjXUYzEO50niuSr4cjLUE4OUfby6/k9sPFIEDXJ2VJAToNtZ0M M720rXDhs74CSpMh4XrV3tZHRAsvAt4+8JhyOh2uOPiieLWFVG7j8YyFyiKlonpw2/SwC8CCm7i m7DkWTGQ+sRiGXrSh4y244EjDJtkEMOs/EVVZNsbcDe9dbXeEkEvoyUDB5s/6G8XV7e5V8IJ0YS n5hRvd2kRZoBh5BZ4KJ1z9D5A= X-Gm-Gg: ASbGncti+lnKXIPyRH6YT0bFG5J7MNizbFYI4XDTbcHeoF2E2vP2xe6cLKw97rD/c8l LsPMgjAWWWcaegculghc0O92gFicUjs4t2yduLixcOB/84P0y12I6IqFtd+4qAvqMPeQChh6CAs wXXIDb X-Received: by 2002:a05:6902:228d:b0:e81:9ebf:f5ed with SMTP id 3f1490d57ef6-e81a226a62dmr1945947276.1.1749158160143; Thu, 05 Jun 2025 14:16:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHb2rG2d+9fop1XPRUg94ju87oBPhimyPjoI4Ye2fKsZq+dhB515YFqLZyXsjORvVHzCfDPRC8LU2/J90no5JA= X-Received: by 2002:a05:6902:228d:b0:e81:9ebf:f5ed with SMTP id 3f1490d57ef6-e81a226a62dmr1945917276.1.1749158159774; Thu, 05 Jun 2025 14:15:59 -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> <0a1dab1c-80d2-436f-857f-734d95939aec@redhat.com> In-Reply-To: <0a1dab1c-80d2-436f-857f-734d95939aec@redhat.com> From: Tal Zussman Date: Thu, 5 Jun 2025 17:15:49 -0400 X-Gm-Features: AX0GCFsgrid_kqSVQH8gQAr68i4R2zJRlWIOJnyZmu8rrEwiMxn2I5F4znJwQ4U Message-ID: Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd To: David Hildenbrand Cc: Peter Xu , 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-Spam-Details-Enc: AW1haW4tMjUwNjA1MDE5MSBTYWx0ZWRfX06nvbAcjk49l 0u94L4yM1vCyuhuqDORT4rFvdIbo/avgxOlsgzffmzNhK3vFhs3h48QTcOXi5dM9u6iktYncYvA 2ud/1axbDAcj1ZTOEkmH6lnYDidErswOgtL8tABqU6Qj/QzCnRudhFvfcKn/g6B2QVxeivcJwLY fFNVLcguZW/nNUb4VaaYXC/wl0Gyi63x9fvKx0zESAYlVQyYb9B20ZHoezWS7HzUV2vwID+jbW+ pGVHVMuMGE7NDXi8hl+rNYeoXTdwq/aSUyHYaNNJzhnQazwr4RxJDgtox239ZP995yvQSNyaRWl e3pmqasjKtxw4gAbpj009z0WwNPbRH5n0NavH5ydRpdAvfjRjdygNCtur4+u06io4hpYXRMLdL2 PlyrhhXh X-Proofpoint-GUID: UZ9suNr9uD-idquC827ct5lOESwMxswF X-Proofpoint-ORIG-GUID: UZ9suNr9uD-idquC827ct5lOESwMxswF 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 priorityscore=1501 bulkscore=10 suspectscore=0 mlxlogscore=836 clxscore=1015 spamscore=0 mlxscore=0 lowpriorityscore=10 malwarescore=0 impostorscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506050191 X-Rspamd-Queue-Id: D61521C000F X-Stat-Signature: kqakg71p91b3dhrku8ihpb5ne6dbhtxk X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1749158162-298261 X-HE-Meta: U2FsdGVkX1+dpF/2cISWx5HY3May2jxHRDhx8f9o8NnLpy559oNbtaHf+G8TAgULt4zqbogMH92cFLvh/wbrzJKsv+4PsEmiqB+FlFCAgNWsEbE+ZdHLOe93z0/cvxn4gIgBfU1dpmv7TsIZ+UFPutnYGYPIXg7FqDk1xWKhZSluPm2YezgmpLf9X36KbxLodZxDbTX9xYO+5sZ9zQ9P2jAPaJue4hT/A39OizmUXEKIIyLP3Pj9IUbbQlqHBE9lZU/r7RzYOiIfy7GU51CKkzFo8VypMqHWIYYKRwfVRNrGXryLmORwdIEEQG5h7QBvrC9qOUEDkQOwGorTROL8FWw7sSuLj6mflOXM6XmKV2zCZGcF4tXy7YBwo4cZmNvFk/03S7A1S0bLwTi4RIJP29QAuc9U2rMcJETt4XI3cjLSubvzmsIWbY/otmCTJ4nZAsvJfLTMtqq6eMuEC5MSKbtu3sfRI3oj5meAl7/DVgE9FVmKXVIKQJXExGu+ipvhtzuMz3vUlhwrqQIAnSY1l55y3GmNCSBCjjS1RwtQzXTR4vu2rGbOVi5adnXr0nhtOo9cvisa9cIkOv+hV6ynS0opSnm/NJLFXXxfudoFiZ/evz+7ndOP/80Zx56nqQKIIxR45w1gaMBNaH0MsxMFlzvSGZ2Vi6Mh56N2PzeX2Bl813+srRASc4WHsyEs6I8/GhAkoNZvt8Y/CDMGe02NbB0n8bRJ8ClO269UtWGiRON9qwEidkq7F8NZrOQUyqUeYSTn/1MB8NLiZBD/Gy4Fy/ltsOsvq1Ey6VbuGZ6wiF+Cu2bZIR2ZMwqxbURynE8EJyVI32BNvWXNBkUnxqS8HjCHCVh7FTRM2XqJGxvjfMJtWpacg734P2tNSC6liUOr//MbWryiiVscwhtI1Wz8l8xp8ta897MZmybfKEC0iqtBg0T9wOzs9ILpjWnDNg59OUzKkzsrBH6s3LwWaE2 Nrzv9x6o EZFs8ukbdPwOaR9d3xt/L1SjEPxebV4KZtC/gGRSH9fPsgLcfDnn3iLTokfMEOTUyBxOgEdqaWVqJObcCs/d3WBoujAIQ6YakJZy4CYPCKPUhs4mVvtAGY4g0hwTT+fcEpB4ENERJDZBm+taROQDRYibqlumwzuI3y4BhlFfvRaGAznYy7G+Ly6rbmBBQm+B2S4dyMYVvGtdPCTtjdEDBQk/Qv7GaF+wmdAIjQBoyXO+B4lxfviflJ1dRAWmtCIqnfXHFYx6OAhniNXZE01MQ2V3XssqdGBu3Dw8YqrCktt+FLBRtfWcfw1cdgw31fBqz6bzJ 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 Thu, Jun 5, 2025 at 5:06=E2=80=AFPM David Hildenbrand = wrote: > > On 04.06.25 17:09, 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_REGI= STER(2const)). > > > > So it sounds still possible if we have existing userapp creating multip= le > > userfaultfds (for example, for scalability reasons on using multiple > > queues) to manage its own mm address space, one uffd in charge of a por= tion > > of VMAs, then it can randomly take one userfaultfd to do unregistration= s. > > Such might break. > > Not sure if relevant, but consider the following: > > an app being controlled by another process using userfaultfd. > > The app itself can "escape" uffd control of the other process by simply > creating a userfaultfd and unregistering VMAs. Yes, this is exactly what I was thinking. Or (less likely) a child process that inherits a uffd from its parent can then mess with memory the parent registers with a different uffd after the fork. > -- > Cheers, > > David / dhildenb >