From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F37AF285068 for ; Thu, 14 May 2026 00:54:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778720092; cv=none; b=HidlMdfPSP4B2NJ86dYBGq8+neWBfpwhp1s6tj8wV3vhAuSveP/Q8bIMpBjjTBby48BFgUOjXln1FM3azwY/ckuCf5s7UvWL2ZVDV9u1gN+FVv+ZHVvXzhH4CACFWB80zCDqAjP6Gtjm4VkjKLfxAZs1Y/7OrJs8+1PNO5Mb20Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778720092; c=relaxed/simple; bh=2GjVt4vEyVIgPuF9Wotu4WEZ8NBQtxFNvvX/cbnYBrM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HhPoneOLz6Cf/xqvX8lxuj4ClgRT5rimepKqJvmcISYoTavYRzmPsA49YGfEAuud7sX6SrkHWMunXjo+IzhI+8ySgS/WR5P1CeXTnWXwoBreDi6ij3nXw09u6jbdcwdYbvrUMgJeljTBm3h4fIX8BnqvYmf0LJ6Hjv9t9OOMuxs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l28xnRl7; arc=none smtp.client-ip=209.85.219.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l28xnRl7" Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-8acae26e564so73546066d6.2 for ; Wed, 13 May 2026 17:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778720090; x=1779324890; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=O0HH69l0JaFi4hHvraUko+G+U6R9D6gJaVlDkjn8xUM=; b=l28xnRl73HjgSG7IwlmmYlGn6esLPR2HfBHl/ezDkbkFmzzsL2OlXmMpTnMIgWHvHV oTehTtGKpZNBKuIdYmexQ284Zp1bvX/PmYtxWNgH8Cd6fiwz1LjF7waJBmuTdaPeHv01 O+6thUXTT7EIY2p/921HYOoYaAHsEIzu3xYwfI6A0odYzwgGN/BV3LaFSDXI6r+irvkB 770l5YleyLMCRP5Q4APb1P/iq+i7lGib7zXKy//YebbGkbmHrxYTU4NAEd0LMFvttxbJ fh+c74m7RV7O6LvHg9f87K/v43iA/Kdaj6yjOM7+LSw8SoKXEkVXCD4vkJGEYcIblLtb q4Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778720090; x=1779324890; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=O0HH69l0JaFi4hHvraUko+G+U6R9D6gJaVlDkjn8xUM=; b=Kq41Kh2hhCSuVcg2APeAPThopGGWa/07jeVu3d3Cpx5NagTWDuCLX12IHcadqjAT1Y gqvAJflfOmqDFJjR/0t5NGJ/p+JUmHc4SAi5VnCDBBjM9QgvC3Z+87DEsdfl5uEpvCfC raPRX6h8bYp0zxy4owVzgh0l0dmgTDCFznwE9MrL5FTwQ1az27LW/pA59ygqQt0MIFF7 OnMsH43v+C+fJ+jiOPV6eYS097dXdx1exjTScd4XhPZpToTpz9GnyXepBYlKnxeqmIH2 88qO00CueMl3FhYTARnZ79hpKeV2ouKS35UYTU0nED0yDYOzrInhk/pDyiS6IX6cJf7+ fPBQ== X-Forwarded-Encrypted: i=1; AFNElJ9e3AJ1ImVRBLW3+kzQhX6b0+fPC5e1s+eEBpoQ7OhgLJqOEKtpX0hqQ0+/kXmkQDNEcR04mzLIbIF11Xk=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2q5dHGu/D1JSb3aZLz4+rPUscYdNvoQoqN2Bq+GiGLNa+qd/J HJK95vw6nxYr6VjfKQWzDF7kUb+9/CDWaqTs6QuG0rEMfKGO6pu/yN5U X-Gm-Gg: Acq92OEK1VAVNSmoutn1+OobZQ4nhDM5QQi/hysVYxhnvI4/EKmzS4TqU15FX6q5P1F Ardnxx8fuLjwf/8j9V0riXrFwQY5z5HWSNK2m4T4434Y0Ez/68a3OL9geHy5gVAMyn6H1uvTFaR 2WH6dpIxdZau0D306a8ZGItX8MQLf0rOVahDdkmxDVlfO7zTj2HtBiOOvfYfzu0Rx26N/XvHtsO /bajCFHnZG7s10iuBrSSKbQJDwWtnK5fySLH5YiduPQ0+T+JbaIbXdVyFr7XC768vw9h6B9B69i NfKCcG/tLIKXNhoHmOzaQ+CDgIMO6WcHyGtRzyF+oynzeKJsn3bOjAoQXbYOxhal72el86Wr4/M W3mi0Xst6N8a4LDOJKZD6tqfLrWjfMnwKbC5Bzwkrr7GP0l/cI2qa3mbcsflowZiNiVgZHtS3eF tDN4ZqaTSuN8xGeIn/8Rv4T6+Aa696FWfSNJkC0sYoaJGXev/EeMYDBcpDdZfklietcjnfDbRJL l2BwIj+GtX1UFZn9MNBZcUx+VyF13HlbKm9s/wOB0QY37QUCPggtQ== X-Received: by 2002:a0c:f10e:0:b0:8b3:fb6a:d35d with SMTP id 6a1803df08f44-8c7bc917691mr74116826d6.47.1778720089931; Wed, 13 May 2026 17:54:49 -0700 (PDT) Received: from server0.tail6e7dd.ts.net (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8c908e11929sm10399986d6.14.2026.05.13.17.54.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 17:54:49 -0700 (PDT) From: Michael Bommarito To: Andrew Morton , Mike Rapoport , Peter Xu Cc: David Carlier , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/1] mm/userfaultfd: fix UFFDIO_COPY retry private/shared VMA panic Date: Wed, 13 May 2026 20:54:39 -0400 Message-ID: <20260514005440.3361406-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Hi, mfill_copy_folio_retry() drops the destination VMA lock before copy_from_user() and reacquires it afterwards. Commit 292411fda25b ("mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()") added a comparison of vma_uffd_ops() across that window, but the comparison is not tight enough for private/shared shmem swaps: both private and shared shmem VMAs expose shmem_uffd_ops through vm_ops, while UFFDIO_COPY into a MAP_PRIVATE file-backed VMA overrides the effective copy ops to anon_uffd_ops at mfill_atomic_pte_copy() time. If the destination is replaced from MAP_PRIVATE shmem to MAP_SHARED shmem during the retry, vma_uffd_ops() still compares equal across the window, the override flip is not detected, and the stale anonymous folio is installed into the new shared shmem VMA. mfill_atomic_install_pte() sees a folio without page-cache mapping, calls folio_add_new_anon_rmap(), and __folio_set_anon() reaches BUG_ON(!anon_vma) because the new shared shmem VMA has no anon_vma. Reproducer (UML+KASAN, 7.1-rc2-00002-g8d90b09e6741, unprivileged uid 65534 with vm.unprivileged_userfaultfd=1): pre-fix: PROCESS_UID=65534 EUID=65534 DST_INITIAL=MAP_PRIVATE_SHMEM addr=0x40041000 SRC_INITIAL=UFFD_MISSING_ANON addr=0x40042000 SOURCE_USERFAULT addr=0x40042000 flags=0x0 DST_REPLACED_WITH_SHARED=ok DST_REREGISTERED_AFTER_REMAP=ok SOURCE_RESOLVED=ok BUG: failure at mm/rmap.c:1468/__folio_set_anon()! Kernel panic - not syncing: BUG! post-fix: DST_UFFDIO_COPY_IOCTL_RET=-1 errno=11 copy=-11 RETRY_RESULT=-11 (no BUG / WARN / KASAN signal in dmesg) The patch introduces a vma_uffd_copy_ops() helper that applies the MAP_PRIVATE override inline. mfill_copy_folio_retry() now compares both the raw vma_uffd_ops() and the effective copy ops across the dropped-lock window: the raw comparison preserves 292411fda25b's VMA-type replacement guard, while the effective comparison catches the private/shared shmem override flip. The mfill_atomic_pte_copy() call site goes through the same helper, preserving today's semantics. Because the override is applied on both sides, a stable MAP_PRIVATE shmem VMA returns &anon_uffd_ops on both effective-copy checks and the comparison still succeeds, so the change does not reintroduce the spurious -EAGAIN that v5/v6 of 292411fda25b's series triggered on MAP_PRIVATE shmem (see that series's v6 changelog). A separate concern from Peter Xu's review of v1 of 292411fda25b's series -- replacement with a different shmem VMA carrying the same flags but a different inode -- is out of scope here and is also unaddressed by 292411fda25b. Testing. - x86_64 UML build with KASAN clean. - Reproducer above: pre-fix panics deterministically on the first iteration; post-fix returns -EAGAIN with empty dmesg. - tools/testing/selftests/mm/uffd-stress {anon,shmem,shmem-private} 16M / 4 cpus, 4 bounces each, KASAN-silent on stock and patched. - tools/testing/selftests/mm/uffd-unit-tests on stock and patched: identical pass / skip profile through the events block; both hit the same pre-existing UML arch limitation in the "poison on anon" case at arch/um/kernel/trap.c:198, unrelated to this patch. - scripts/checkpatch.pl --strict clean. Fixes: 292411fda25b ("mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry()") Michael Bommarito (1): mm/userfaultfd: validate effective UFFDIO_COPY ops after retry mm/userfaultfd.c | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) -- 2.46.0