From nobody Sun Feb 8 00:26:15 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C99C5EB64DC for ; Fri, 14 Jul 2023 18:29:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236858AbjGNS3r (ORCPT ); Fri, 14 Jul 2023 14:29:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236842AbjGNS3n (ORCPT ); Fri, 14 Jul 2023 14:29:43 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 458A026BC for ; Fri, 14 Jul 2023 11:29:42 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-c4f27858e4eso1824921276.1 for ; Fri, 14 Jul 2023 11:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689359381; x=1691951381; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=yxAUfh9tXsKn2HpY20y1qdPrUCx+3NBgZb4IkMtE0Gs=; b=mRXoMTCmgDEUqGGQOSIsn5uuIWxzrKXnwuch52uQZkXJzVeF5h7KiOw042B2VG4MjP Ud668hnCaHqrAsJelWng9Y2s3bZEVDGgCwmtA+RKaeDYCfKMRATcF36o9bwXZSjLJXmD xGwtxtYrORJWP/GtvcdJ6DB3nWNbNp1NNsvwoy5dkJJkXV1mjG4ZyIAPBxa0ZeJy47wC lRAwtwRfLuaZHPN6fZIxopQbbbLZSH+r7pelwbYbHYvr6TN2ykZ5n8m7RT6Rx1PDAv41 itfOO1Y5wnapfiZ17WHQSzoXlIaDEkigdLEJ+n13E7rjAc5bMhn9nmE0OvXONw09Gqtv LCkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689359381; x=1691951381; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yxAUfh9tXsKn2HpY20y1qdPrUCx+3NBgZb4IkMtE0Gs=; b=S7hpBXipz5uAjkng/PmGTO7oWInREI6R5HEm321KXtDuF9kO8Q8R4rBnBQMaIAceqa PWoMQLzYKqpl4WTAAF57gJ9c1iKLSzIyVJwxW1H59aVdR6kDuKwQXMfPd14+2WSwaTng nD+xfHO5fmt31bMqO5dxGuSc6yZG/W1ooW5X1TtFKuFUTCmTbFdgwychDMkhw2KrZSnN 8GsCYAmmZ/3LeFEurkrO6NDBQZtg2z7zhsZ65gog5pPwwZYYPl0LBjK9FRgQwkMXa67O xroOI6O7eNAgJaySVJCtU+DNI7WYbcaHn3zG63Uh6ASxTx99tUTrZ/0/ep3dl/ViX8cE KBZQ== X-Gm-Message-State: ABy/qLasva48ehc50DFXg0oVLlHcqDCJxvgtSt1BJkzfbZZVIoufbHm2 74R8ypqDD7jlBFzbXAdJMOw0zlgS8eIfBu+Grt/k X-Google-Smtp-Source: APBJJlHJ/kyB4gtYJRA2tBe4+IdzDMyqED2Fs1IG5ccfZHYtkPxqRy1tdgRGDnnyoyPph5LKlnKkyWQ84gNPe3dqgbnb X-Received: from axel.svl.corp.google.com ([2620:15c:2a3:200:eeac:4e26:b121:5ef2]) (user=axelrasmussen job=sendgmr) by 2002:a25:4157:0:b0:c10:8d28:d3ae with SMTP id o84-20020a254157000000b00c108d28d3aemr26174yba.8.1689359381331; Fri, 14 Jul 2023 11:29:41 -0700 (PDT) Date: Fri, 14 Jul 2023 11:29:32 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.41.0.255.g8b1d071c50-goog Message-ID: <20230714182932.2608735-1-axelrasmussen@google.com> Subject: [PATCH mm-unstable fix] mm: userfaultfd: check for start + len overflow in validate_range: fix From: Axel Rasmussen To: Alexander Viro , Andrew Morton , Brian Geffon , Christian Brauner , David Hildenbrand , Gaosheng Cui , Huang Ying , Hugh Dickins , James Houghton , Jiaqi Yan , Jonathan Corbet , Kefeng Wang , "Liam R. Howlett" , Miaohe Lin , Mike Kravetz , "Mike Rapoport (IBM)" , Muchun Song , Nadav Amit , Naoya Horiguchi , Peter Xu , Shuah Khan , Steven Barrett , Suleiman Souhlal , Suren Baghdasaryan , "T.J. Alumbaugh" , Yu Zhao , ZhangPeng Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Axel Rasmussen , syzbot+42309678e0bc7b32f8e9@syzkaller.appspotmail.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This commit removed an extra check for zero-length ranges, and folded it into the common validate_range() helper used by all UFFD ioctls. It failed to notice though that UFFDIO_COPY *only* called validate_range on the dst range, not the src range. So removing this check actually let us proceed with zero-length source ranges, eventually hitting a BUG further down in the call stack. The correct fix seems clear: call validate_range() on the src range too. Other ioctls are not affected by this, as they only have one range, not two (src + dst). Reported-by: syzbot+42309678e0bc7b32f8e9@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3D42309678e0bc7b32f8e9 Signed-off-by: Axel Rasmussen --- fs/userfaultfd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 53a7220c4679..36d233759233 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1759,6 +1759,9 @@ static int userfaultfd_copy(struct userfaultfd_ctx *c= tx, sizeof(uffdio_copy)-sizeof(__s64))) goto out; =20 + ret =3D validate_range(ctx->mm, uffdio_copy.src, uffdio_copy.len); + if (ret) + goto out; ret =3D validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; --=20 2.41.0.255.g8b1d071c50-goog