From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) (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 BB7264369A for ; Mon, 16 Mar 2026 02:02:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773626541; cv=none; b=bXwF2DQ5Qe5pEqjelsaN31VVMWKgj1cCwrzyGi0W+7vyhB8aBCouBMU2bSg8dFl/2WAClzlLem8IUuOzTvxlw3kf4P6x3gJMkgUOu0pmILdu13onXhttSS4sIGGEkLuGgTs196EORo5JRddhBfe402E+FWQp2Q+WqTTO5cgViNc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773626541; c=relaxed/simple; bh=TiXdP20hjAMryM0DCX6FXgSfql/6iA48WcwCbkDzX/g=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=Ucgc7ysOG4daOe60c5Q3YPDdhEAFg4V+tSWGkp60nNL0zgZMPbWLuVjrxH5wQefMBB1wd4ZhB3YX+kJZV0ph+Tp+f9rkppRpOEQ3EY4GxKETs0XpMvCrGS4yPR745ZhkPCvXw921p9I94aiib/TV6ICHqRRHgN968eDZjdx09MA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.161.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com Received: by mail-oo1-f70.google.com with SMTP id 006d021491bc7-672c40f3873so99132850eaf.2 for ; Sun, 15 Mar 2026 19:02:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773626539; x=1774231339; h=to:from:subject:message-id:in-reply-to:date:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=N7DA11H8xsEShD8HQVFG1R+0cr9wxHmSf6k7Cd70vIM=; b=Zp8cjZuCRva+QRhcJsDBN1OqrRpdthtimvd+eqBfVFYa+E/5qRXTTKwLOC3FfwLtjx LVCdvdJKjQl23eHUuaKRydsFpoRSdZ8FPoXEoez6jtKRNOlmxx/7v2wLIx9U/tqdT6Rg Fw9gyBDH+6VCQVoGp9XEO3hG2TLJkezo8RMqd6k8V2xrzNqzLdEIyNZDI9Y20xcIY6JM LKpqiZfMdiCFZlyDI4Gclj3sg0jy+NpRKyCsknROMmbrl0Wr7ykmTkEgPJkhDg7SdWfA QSaMsPLkeM/WwYnyoGXUIOGnuiNaagNhvm6ROamwHZj2ctLWtg7bCyzuiqIZuK+bJkzB a+9A== X-Gm-Message-State: AOJu0YzFEEVAVw6IBFdVnjKwPlNy+AI6GrC/vGDMOtVFaTae5oS/C7ol s85kAkOHNA5K5Jid1V+nDoVaeHvREmKGjjltgAHPOHU66A58HHjcWYrtqx05RNYheY/4ytiDRO6 8MWfkPJeBQIh9g3OJL+e2imMPR9a/A7t028v95ho1c3FoP97wfarNh5mzvtY= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Received: by 2002:a05:6820:134e:b0:67b:c1f8:a3e8 with SMTP id 006d021491bc7-67bdaa9193amr8025744eaf.66.1773626538680; Sun, 15 Mar 2026 19:02:18 -0700 (PDT) Date: Sun, 15 Mar 2026 19:02:18 -0700 In-Reply-To: <69b703e6.050a0220.248e02.0101.GAE@google.com> X-Google-Appengine-App-Id: s~syzkaller X-Google-Appengine-App-Id-Alias: syzkaller Message-ID: <69b764aa.a00a0220.3b25d1.0020.GAE@google.com> Subject: Forwarded: [PATCH] mm/userfaultfd: re-validate vma in mfill_atomic() loop under CONFIG_PER_VMA_LOCK From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" For archival purposes, forwarding an incoming command email to linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com. *** Subject: [PATCH] mm/userfaultfd: re-validate vma in mfill_atomic() loop under CONFIG_PER_VMA_LOCK Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master Under CONFIG_PER_VMA_LOCK, mfill_atomic() holds only a per-VMA read lock (vma_start_read) across its page-by-page copy loop. Unlike mmap_read_lock, this does not prevent a concurrent mmap_write_lock() from splitting the vma mid-loop via UFFDIO_UNREGISTER. When the vma is split, vm_end of state.vma is shrunk in place. On the next iteration, mfill_atomic_install_pte() calls folio_add_new_anon_rmap() with state.dst_addr >= vma->vm_end, triggering the sanity check: address < vma->vm_start || address + (nr << 12) > vma->vm_end WARNING: mm/rmap.c:1682 folio_add_new_anon_rmap+0x5fe/0x14b0 Fix this by checking on each loop iteration whether state.dst_addr has fallen outside state.vma. If so, release the stale vma, update dst_start and len to reflect the current position, and re-lookup the vma via mfill_get_vma(). Reported-by: syzbot+e24a2e34fad0efbac047@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e24a2e34fad0efbac047 Signed-off-by: Deepanshu Kartikey --- mm/userfaultfd.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 9ffc80d0a51b..519be02fad38 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -910,8 +910,17 @@ static __always_inline ssize_t mfill_atomic(struct userfaultfd_ctx *ctx, while (state.src_addr < src_start + len) { VM_WARN_ON_ONCE(state.dst_addr >= dst_start + len); + if (state.dst_addr < state.vma->vm_start || + state.dst_addr >= state.vma->vm_end) { + mfill_put_vma(&state); + state.dst_start = state.dst_addr; + state.len = dst_start + len - state.dst_addr; + err = mfill_get_vma(&state); + if (err) + break; + } - err = mfill_get_pmd(&state); + err = mfill_get_pmd(&state); if (err) break; -- 2.43.0