From nobody Tue Apr 7 04:58:02 2026 Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) (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 C7FF71D514E for ; Mon, 16 Mar 2026 05:11:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.72 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773637881; cv=none; b=CUAieAlhBPW5y0R0SAO8E+oHBumGM4yR8CM9feVZhUhpJzgE440uJJ0aPQwlT0b38bx/8C247PtSsgFVf/WhnS2PIiAh7PY5/g2uNorykzGBXgvgcqp1BPHVSESaB5ySWoIxpsbh74drxlTsUDAeOk3vpVSsRCKMxvSXo1GqA94= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773637881; c=relaxed/simple; bh=/A+tXTzoHJxTHLIbSn04hOEZC3IXMXRXLJOl37nvhKo=; h=MIME-Version:Date:In-Reply-To:Message-ID:Subject:From:To: Content-Type; b=A0TWyx57enW4Swf2Eo7x6/ip9Ytbfa6qTyne6/IL6wqRFzt3cWYGxFfP6otpckEobaAJCjoynYRnmnoSNo3cXeTXPdKnPmlmyx2cHK0fTVp9or1D5YW6220clhkAYMdDibfH98Hnr2uCooy7SuyFWV95rDhAY168Yj4sbo55yKg= 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.210.72 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-ot1-f72.google.com with SMTP id 46e09a7af769-7d7438fc7f0so19227066a34.0 for ; Sun, 15 Mar 2026 22:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773637879; x=1774242679; 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=Cbrs4hMIbTlLE7N7h0bkd29cSvIvcNQZNPsxxEidzeo=; b=LG3ABhHccqhdnSMNYp6ETd4vIHOn9kG2/h5pgxfmnihC9+ifWAZCd6BGq8+UQ9gI+f mdTmmxOWmU8I8wTzaF+EI0fxw5IpW/KiEhs12eVktlNL5zI86Ii2pRHHMTLGlUTw+oSr H9L2i0Oem18P62VSo5FCxu4im7HH5VY4R4lLgt9swpYsPPBUagEYz9419yifiN059ta7 HGESioKrK0/acSovP4DfjAQtmjkdakGkM1MB4zIG+mt+RN518/VG5grZ1K1+TVPaJ5Od T6tkcAnaSmMFu+jjRwKCHzYmzK4dFH50D8EeVK50OEI/MpaLF3syeXfz3G7HuWx/G0B3 dvcQ== X-Gm-Message-State: AOJu0Yz4X6lLkuhPg1bk3kbYZ/db4gbFQfIMxLkem0juegZObwHS1spm Qr6s9tqG1EcObPkoQMEf9N+cz5bIPiENjbh8MScJTkuLqkcXHkw21IlazgsCI0xg7nyIsVodhrd A2Ji2y4ASPMt04+26MHhOGcxPOMcFlIcDruMWqvqGuroHVmoRTRb+aFqybus= 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:4df9:b0:67b:aef9:1ce5 with SMTP id 006d021491bc7-67bdaa2db8fmr7386200eaf.46.1773637878850; Sun, 15 Mar 2026 22:11:18 -0700 (PDT) Date: Sun, 15 Mar 2026 22:11: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: <69b790f6.a00a0220.3b25d1.0021.GAE@google.com> Subject: Forwarded: [PATCH] mm/userfaultfd: validate dst_addr after re-acquiring VMA lock in mfill_copy_folio_retry From: syzbot To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Transfer-Encoding: quoted-printable 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: validate dst_addr after re-acquiring VMA l= ock in mfill_copy_folio_retry Author: kartikey406@gmail.com #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.gi= t master mfill_copy_folio_retry() drops the VMA lock to perform copy_from_user() without holding it, then reacquires it via mfill_get_vma(). However, mfill_get_vma() only validates that dst_start is within the VMA bounds, not dst_addr (the current page being processed). A concurrent UFFDIO_UNREGISTER can split the VMA during the window where the lock is dropped, shrinking vma->vm_end. When mfill_get_vma() reacquires the lock, it finds the VMA using dst_start which may still be valid, but dst_addr may now fall outside the split VMA's bounds. This causes folio_add_new_anon_rmap() to trigger its 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 validating dst_addr against the reacquired VMA bounds after mfill_get_vma() returns in mfill_copy_folio_retry(). Reported-by: syzbot+e24a2e34fad0efbac047@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3De24a2e34fad0efbac047 Signed-off-by: Deepanshu Kartikey --- mm/userfaultfd.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 9ffc80d0a51b..dbf16c9bcf6f 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -467,6 +467,16 @@ static int mfill_copy_folio_retry(struct mfill_state *= state, struct folio *folio if (err) return err; =20 + /* + * VMA may have been split while the lock was dropped for + * copy_from_user(). mfill_get_vma() only validates dst_start + * but not dst_addr (current page). Re-validate dst_addr against + * the reacquired VMA bounds before installing the PTE. + */ + if (state->dst_addr < state->vma->vm_start || + state->dst_addr >=3D state->vma->vm_end) + return -EFAULT; + err =3D mfill_get_pmd(state); if (err) return err; --=20 2.43.0