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 X-Spam-Level: X-Spam-Status: No, score=-26.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0003C11F67 for ; Wed, 7 Jul 2021 18:43:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7F5D61CCD for ; Wed, 7 Jul 2021 18:43:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231922AbhGGSqD (ORCPT ); Wed, 7 Jul 2021 14:46:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231646AbhGGSqD (ORCPT ); Wed, 7 Jul 2021 14:46:03 -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 B69E1C061762 for ; Wed, 7 Jul 2021 11:43:21 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id t11-20020a056902124bb029055a821867baso17386847ybu.14 for ; Wed, 07 Jul 2021 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=K+LM7F0IB0aSYNtOvg0E9GvXKjCLql5DSPqjvVB86twQXXyF/q6PHxDdU+BFLULHal sadBOrS4uDhUi3ch0QwQHNPBTWqBtvn7g/9tCpsvnCthWK16fCqiUndoAyS08PGjQo6S 2LBmWo+Mo4tbLwf8vdGc9MzdPAjGe1ayDo+fSkgL8CGutBMUW6MdTioWibNdlSj5eKsi jqRpLGtz+zlNzVV8jVz3wc4uU7vdEhNf5H9BoyOH0O15axjOZz9b1nCjjMgUprGCD7CN 39vnltrjCKQfAZLxNBUfMsKbjjpOP84V3OLtSj+2LV1xEwNEpeOWu10XgJp+dXLWp34b ZFhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=K4eRzNl1lSLWhl7ag1iHUWdWosEH8TOsc3zSCEUDxYXuQIpPquWpydc97Dxna63vJU BrogDpIGNSFWHzQhnPn8LykFkUEE+tTkqh/+tYFOGZUgwKYhiqgsvZbfDKZpJSK/dZsD Arvq58E2iGrtWtdm9rYQpOeweNbr6IWfDD6dk7A2kNIHzIdMdEonhN5OAFXivvBPHrJC CeMCnSB4c8e+s7gRPiZUTSX8Lq33siTGH34NBBXCbrJz9MjnghzMuD/5PfqnfC0qaEho 3Dpl2ASbVcQNJe+JOW0J94ZOnDD+81VFvXx51+CJ+BMFlALrM9VTVUqwIvO3wmQ6agVq Y/hA== X-Gm-Message-State: AOAM530XoH1ANObRM1URjo9QgukigtFmP5hcMhqlThbfD1nSAX/MeYcY m2DGcplcOFce6auGvuhWi5dGbtU= X-Google-Smtp-Source: ABdhPJzfsRJUloKscyxRckLCLZ2ozVeHI7bDJY4UJtahYxURZSftvGl/YpEKOwF+37yu/uiTBkRJFIw= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2ce:200:3b71:8b83:5f3c:e3df]) (user=pcc job=sendgmr) by 2002:a25:4095:: with SMTP id n143mr31599183yba.22.1625683400900; Wed, 07 Jul 2021 11:43:20 -0700 (PDT) Date: Wed, 7 Jul 2021 11:43:12 -0700 In-Reply-To: <20210707184313.3697385-1-pcc@google.com> Message-Id: <20210707184313.3697385-2-pcc@google.com> Mime-Version: 1.0 References: <20210707184313.3697385-1-pcc@google.com> X-Mailer: git-send-email 2.32.0.93.g670b81a890-goog Subject: [PATCH v4 1/2] userfaultfd: do not untag user pointers From: Peter Collingbourne To: Catalin Marinas , Vincenzo Frascino , Dave Martin , Will Deacon , Andrew Morton , Andrea Arcangeli Cc: Peter Collingbourne , Alistair Delva , Lokesh Gidra , William McVicker , Evgenii Stepanov , Mitch Phillips , Linux ARM , linux-mm@kvack.org, Andrey Konovalov , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Cc: # 5.4 --- v4: - document the changes more accurately - fix new calls to validate_range Documentation/arm64/tagged-address-abi.rst | 26 +++++++++++++++------- fs/userfaultfd.c | 26 ++++++++++------------ 2 files changed, 30 insertions(+), 22 deletions(-) diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..0c9120ec58ae 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index dd7a6c62b56f..27af6b82a758 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1236,23 +1236,21 @@ static __always_inline void wake_userfault(struct userfaultfd_ctx *ctx, } static __always_inline int validate_range(struct mm_struct *mm, - __u64 *start, __u64 len) + __u64 start, __u64 len) { __u64 task_size = mm->task_size; - *start = untagged_addr(*start); - - if (*start & ~PAGE_MASK) + if (start & ~PAGE_MASK) return -EINVAL; if (len & ~PAGE_MASK) return -EINVAL; if (!len) return -EINVAL; - if (*start < mmap_min_addr) + if (start < mmap_min_addr) return -EINVAL; - if (*start >= task_size) + if (start >= task_size) return -EINVAL; - if (len > task_size - *start) + if (len > task_size - start) return -EINVAL; return 0; } @@ -1313,7 +1311,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, vm_flags |= VM_UFFD_MINOR; } - ret = validate_range(mm, &uffdio_register.range.start, + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) goto out; @@ -1519,7 +1517,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; - ret = validate_range(mm, &uffdio_unregister.start, + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) goto out; @@ -1668,7 +1666,7 @@ static int userfaultfd_wake(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_wake, buf, sizeof(uffdio_wake))) goto out; - ret = validate_range(ctx->mm, &uffdio_wake.start, uffdio_wake.len); + ret = validate_range(ctx->mm, uffdio_wake.start, uffdio_wake.len); if (ret) goto out; @@ -1708,7 +1706,7 @@ static int userfaultfd_copy(struct userfaultfd_ctx *ctx, sizeof(uffdio_copy)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_copy.dst, uffdio_copy.len); + ret = validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; /* @@ -1765,7 +1763,7 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx, sizeof(uffdio_zeropage)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_zeropage.range.start, + ret = validate_range(ctx->mm, uffdio_zeropage.range.start, uffdio_zeropage.range.len); if (ret) goto out; @@ -1815,7 +1813,7 @@ static int userfaultfd_writeprotect(struct userfaultfd_ctx *ctx, sizeof(struct uffdio_writeprotect))) return -EFAULT; - ret = validate_range(ctx->mm, &uffdio_wp.range.start, + ret = validate_range(ctx->mm, uffdio_wp.range.start, uffdio_wp.range.len); if (ret) return ret; @@ -1863,7 +1861,7 @@ static int userfaultfd_continue(struct userfaultfd_ctx *ctx, unsigned long arg) sizeof(uffdio_continue) - (sizeof(__s64)))) goto out; - ret = validate_range(ctx->mm, &uffdio_continue.range.start, + ret = validate_range(ctx->mm, uffdio_continue.range.start, uffdio_continue.range.len); if (ret) goto out; -- 2.32.0.93.g670b81a890-goog 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 X-Spam-Level: X-Spam-Status: No, score=-26.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9725EC07E95 for ; Wed, 7 Jul 2021 18:50:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3619261CAA for ; Wed, 7 Jul 2021 18:50:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3619261CAA Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1DAD76B0092; Wed, 7 Jul 2021 14:50:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18ABB6B0098; Wed, 7 Jul 2021 14:50:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 004C66B0099; Wed, 7 Jul 2021 14:50:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0099.hostedemail.com [216.40.44.99]) by kanga.kvack.org (Postfix) with ESMTP id CC7886B0092 for ; Wed, 7 Jul 2021 14:50:44 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 35DC82439C for ; Wed, 7 Jul 2021 18:50:44 +0000 (UTC) X-FDA: 78336683208.39.D243E54 Received: from mail-ot1-f73.google.com (mail-ot1-f73.google.com [209.85.210.73]) by imf15.hostedemail.com (Postfix) with ESMTP id D13C1D00009C for ; Wed, 7 Jul 2021 18:50:43 +0000 (UTC) Received: by mail-ot1-f73.google.com with SMTP id a60-20020a9d26420000b0290448d2be15e6so2213670otb.23 for ; Wed, 07 Jul 2021 11:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=K+LM7F0IB0aSYNtOvg0E9GvXKjCLql5DSPqjvVB86twQXXyF/q6PHxDdU+BFLULHal sadBOrS4uDhUi3ch0QwQHNPBTWqBtvn7g/9tCpsvnCthWK16fCqiUndoAyS08PGjQo6S 2LBmWo+Mo4tbLwf8vdGc9MzdPAjGe1ayDo+fSkgL8CGutBMUW6MdTioWibNdlSj5eKsi jqRpLGtz+zlNzVV8jVz3wc4uU7vdEhNf5H9BoyOH0O15axjOZz9b1nCjjMgUprGCD7CN 39vnltrjCKQfAZLxNBUfMsKbjjpOP84V3OLtSj+2LV1xEwNEpeOWu10XgJp+dXLWp34b ZFhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=ax2aLJ87TY0hB4SAJ2sJ+PtIXjT+pNHLtPD27YCBXxqvaih0B7Tvmvn2kpRvCtbKSC EwHcJsPWJy1Xai6feALEURaiD0sNn230sngAfbhSTI7syGP7OtaDluMxxyUceiWcEQ8n n8xaWg5vvD9N8rUxnhU+XNsOZSFJNhle3IcG0ywhv1rCsdacc89cuSGc9x3F2tvQKkWE x9dzWo3/hfq522QvBRKl/fy644Bn7NgukTHW/4GgFIZMxF0s5ONn0MG6Dwbvk8zaZOuS Lu3FFGqV2PGU3E+vL1OAYC5nTf4TnSfkzNffvYVMNxErjRxH/vsZhLvIuJizJd5Ak9NM paGA== X-Gm-Message-State: AOAM531tiJvXmivbsJYfn+bZJiAbRWJ/irPY/m7efuaG+AkUy7m4gYxz Ck2udJ1DBtptxLwGebQ4NnMcWK8= X-Google-Smtp-Source: ABdhPJzfsRJUloKscyxRckLCLZ2ozVeHI7bDJY4UJtahYxURZSftvGl/YpEKOwF+37yu/uiTBkRJFIw= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2ce:200:3b71:8b83:5f3c:e3df]) (user=pcc job=sendgmr) by 2002:a25:4095:: with SMTP id n143mr31599183yba.22.1625683400900; Wed, 07 Jul 2021 11:43:20 -0700 (PDT) Date: Wed, 7 Jul 2021 11:43:12 -0700 In-Reply-To: <20210707184313.3697385-1-pcc@google.com> Message-Id: <20210707184313.3697385-2-pcc@google.com> Mime-Version: 1.0 References: <20210707184313.3697385-1-pcc@google.com> X-Mailer: git-send-email 2.32.0.93.g670b81a890-goog Subject: [PATCH v4 1/2] userfaultfd: do not untag user pointers From: Peter Collingbourne To: Catalin Marinas , Vincenzo Frascino , Dave Martin , Will Deacon , Andrew Morton , Andrea Arcangeli Cc: Peter Collingbourne , Alistair Delva , Lokesh Gidra , William McVicker , Evgenii Stepanov , Mitch Phillips , Linux ARM , linux-mm@kvack.org, Andrey Konovalov , stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: nil Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=K+LM7F0I; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of 3yPXlYAMKCFkG337FF7C5.3FDC9ELO-DDBM13B.FI7@flex--pcc.bounces.google.com designates 209.85.210.73 as permitted sender) smtp.mailfrom=3yPXlYAMKCFkG337FF7C5.3FDC9ELO-DDBM13B.FI7@flex--pcc.bounces.google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D13C1D00009C X-Stat-Signature: kiifh5nm81np544mrpoy75bn5q9wfych X-HE-Tag: 1625683843-626653 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: If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Cc: # 5.4 --- v4: - document the changes more accurately - fix new calls to validate_range Documentation/arm64/tagged-address-abi.rst | 26 +++++++++++++++------- fs/userfaultfd.c | 26 ++++++++++------------ 2 files changed, 30 insertions(+), 22 deletions(-) diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..0c9120ec58ae 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index dd7a6c62b56f..27af6b82a758 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1236,23 +1236,21 @@ static __always_inline void wake_userfault(struct userfaultfd_ctx *ctx, } static __always_inline int validate_range(struct mm_struct *mm, - __u64 *start, __u64 len) + __u64 start, __u64 len) { __u64 task_size = mm->task_size; - *start = untagged_addr(*start); - - if (*start & ~PAGE_MASK) + if (start & ~PAGE_MASK) return -EINVAL; if (len & ~PAGE_MASK) return -EINVAL; if (!len) return -EINVAL; - if (*start < mmap_min_addr) + if (start < mmap_min_addr) return -EINVAL; - if (*start >= task_size) + if (start >= task_size) return -EINVAL; - if (len > task_size - *start) + if (len > task_size - start) return -EINVAL; return 0; } @@ -1313,7 +1311,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, vm_flags |= VM_UFFD_MINOR; } - ret = validate_range(mm, &uffdio_register.range.start, + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) goto out; @@ -1519,7 +1517,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; - ret = validate_range(mm, &uffdio_unregister.start, + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) goto out; @@ -1668,7 +1666,7 @@ static int userfaultfd_wake(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_wake, buf, sizeof(uffdio_wake))) goto out; - ret = validate_range(ctx->mm, &uffdio_wake.start, uffdio_wake.len); + ret = validate_range(ctx->mm, uffdio_wake.start, uffdio_wake.len); if (ret) goto out; @@ -1708,7 +1706,7 @@ static int userfaultfd_copy(struct userfaultfd_ctx *ctx, sizeof(uffdio_copy)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_copy.dst, uffdio_copy.len); + ret = validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; /* @@ -1765,7 +1763,7 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx, sizeof(uffdio_zeropage)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_zeropage.range.start, + ret = validate_range(ctx->mm, uffdio_zeropage.range.start, uffdio_zeropage.range.len); if (ret) goto out; @@ -1815,7 +1813,7 @@ static int userfaultfd_writeprotect(struct userfaultfd_ctx *ctx, sizeof(struct uffdio_writeprotect))) return -EFAULT; - ret = validate_range(ctx->mm, &uffdio_wp.range.start, + ret = validate_range(ctx->mm, uffdio_wp.range.start, uffdio_wp.range.len); if (ret) return ret; @@ -1863,7 +1861,7 @@ static int userfaultfd_continue(struct userfaultfd_ctx *ctx, unsigned long arg) sizeof(uffdio_continue) - (sizeof(__s64)))) goto out; - ret = validate_range(ctx->mm, &uffdio_continue.range.start, + ret = validate_range(ctx->mm, uffdio_continue.range.start, uffdio_continue.range.len); if (ret) goto out; -- 2.32.0.93.g670b81a890-goog 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 X-Spam-Level: X-Spam-Status: No, score=-18.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0AFFDC07E9C for ; Wed, 7 Jul 2021 18:44:52 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D1FA060720 for ; Wed, 7 Jul 2021 18:44:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1FA060720 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:References: Mime-Version:Message-Id:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=RCIqCT3pAxpPDDdbQ01pf+NKg29rJxNcqi7ULvLVyn8=; b=sw5SQn8nq2dv8Y1BCUgQXr1v1Z Rg4krb0YUWAWIP/rc9mA3xvK5GdXczPhES6aGXaF+7+c+GBFTk2ras855qLRFfIrhQUg0Yn/j7DFl LRxuCEKonn3eGci8lHGSDzGCAV6GIJgTgrLVBcxExLmD2rL15NhQldsje2mLt4dJ9BS3wg5w67g4O MJdRVJ4LTovdRkQs2XODloIyntvYuh/3Xl81SEI/KyNppySJRCmC9lB+BZC/oHihj4bo4zAybStSd xTkAtb6AEHD2ZkZ1IYetZAN68vqoKZQdLtxtVlJH7ZhpCq0HMkMTKZigWBNHA+7ktskm8WHHBVHfP sxAzwl/Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1CWF-00FWx2-UY; Wed, 07 Jul 2021 18:43:36 +0000 Received: from mail-yb1-xb49.google.com ([2607:f8b0:4864:20::b49]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1CW2-00FWql-JA for linux-arm-kernel@lists.infradead.org; Wed, 07 Jul 2021 18:43:24 +0000 Received: by mail-yb1-xb49.google.com with SMTP id o12-20020a5b050c0000b02904f4a117bd74so3697336ybp.17 for ; Wed, 07 Jul 2021 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=K+LM7F0IB0aSYNtOvg0E9GvXKjCLql5DSPqjvVB86twQXXyF/q6PHxDdU+BFLULHal sadBOrS4uDhUi3ch0QwQHNPBTWqBtvn7g/9tCpsvnCthWK16fCqiUndoAyS08PGjQo6S 2LBmWo+Mo4tbLwf8vdGc9MzdPAjGe1ayDo+fSkgL8CGutBMUW6MdTioWibNdlSj5eKsi jqRpLGtz+zlNzVV8jVz3wc4uU7vdEhNf5H9BoyOH0O15axjOZz9b1nCjjMgUprGCD7CN 39vnltrjCKQfAZLxNBUfMsKbjjpOP84V3OLtSj+2LV1xEwNEpeOWu10XgJp+dXLWp34b ZFhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=fBecXpdoiWZRY4lnkZjFBk2ArEoGd2LP5hh3zPDWUYc=; b=eUadpeqlYC3boomRxbZYLVvlvI5Sr5dkcbqGFgPxsVOzXFjI0lwc+Wmvs+lwM7ZzLE GTcnTGjLCT1VGlnbEqFeQ06FVEygoREYvM68460oCiykTmxSw/L4Y3D01nWTRrun4ASi W7MfK/sqLHsKBZsrWcwE0o+ilSmKRyR+15SCOEBH3Twpp6+YcChJc8hWoigu1RMyvmei vmQDnPTDQDBj89l48/JxG9MKjMNlrSk7KYReWWlIOT/23+KwrBjnMShX+fH7SgqdW/rG Yb6pzdgm4QBfM0+Nmd27/HZk1yozJCMlkbmC9RgapM8C9RaME4O/9ObxDCwkwL9nkdHx phuA== X-Gm-Message-State: AOAM531ieBKf3B5eJF/CSe/C2laY2GNjzucwfnmlzQd0+swFtBgEzX9x fW/NMUeDII9N/HV+bOuGAAFyCR4= X-Google-Smtp-Source: ABdhPJzfsRJUloKscyxRckLCLZ2ozVeHI7bDJY4UJtahYxURZSftvGl/YpEKOwF+37yu/uiTBkRJFIw= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2ce:200:3b71:8b83:5f3c:e3df]) (user=pcc job=sendgmr) by 2002:a25:4095:: with SMTP id n143mr31599183yba.22.1625683400900; Wed, 07 Jul 2021 11:43:20 -0700 (PDT) Date: Wed, 7 Jul 2021 11:43:12 -0700 In-Reply-To: <20210707184313.3697385-1-pcc@google.com> Message-Id: <20210707184313.3697385-2-pcc@google.com> Mime-Version: 1.0 References: <20210707184313.3697385-1-pcc@google.com> X-Mailer: git-send-email 2.32.0.93.g670b81a890-goog Subject: [PATCH v4 1/2] userfaultfd: do not untag user pointers From: Peter Collingbourne To: Catalin Marinas , Vincenzo Frascino , Dave Martin , Will Deacon , Andrew Morton , Andrea Arcangeli Cc: Peter Collingbourne , Alistair Delva , Lokesh Gidra , William McVicker , Evgenii Stepanov , Mitch Phillips , Linux ARM , linux-mm@kvack.org, Andrey Konovalov , stable@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210707_114322_718971_C4A21DEF X-CRM114-Status: GOOD ( 26.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org If a user program uses userfaultfd on ranges of heap memory, it may end up passing a tagged pointer to the kernel in the range.start field of the UFFDIO_REGISTER ioctl. This can happen when using an MTE-capable allocator, or on Android if using the Tagged Pointers feature for MTE readiness [1]. When a fault subsequently occurs, the tag is stripped from the fault address returned to the application in the fault.address field of struct uffd_msg. However, from the application's perspective, the tagged address *is* the memory address, so if the application is unaware of memory tags, it may get confused by receiving an address that is, from its point of view, outside of the bounds of the allocation. We observed this behavior in the kselftest for userfaultfd [2] but other applications could have the same problem. Address this by not untagging pointers passed to the userfaultfd ioctls. Instead, let the system call fail. This will provide an early indication of problems with tag-unaware userspace code instead of letting the code get confused later, and is consistent with how we decided to handle brk/mmap/mremap in commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()"), as well as being consistent with the existing tagged address ABI documentation relating to how ioctl arguments are handled. The code change is a revert of commit 7d0325749a6c ("userfaultfd: untag user pointers") plus some fixups to some additional calls to validate_range that have appeared since then. [1] https://source.android.com/devices/tech/debug/tagged-pointers [2] tools/testing/selftests/vm/userfaultfd.c Signed-off-by: Peter Collingbourne Reviewed-by: Andrey Konovalov Link: https://linux-review.googlesource.com/id/I761aa9f0344454c482b83fcfcce547db0a25501b Fixes: 63f0c6037965 ("arm64: Introduce prctl() options to control the tagged user addresses ABI") Cc: # 5.4 --- v4: - document the changes more accurately - fix new calls to validate_range Documentation/arm64/tagged-address-abi.rst | 26 +++++++++++++++------- fs/userfaultfd.c | 26 ++++++++++------------ 2 files changed, 30 insertions(+), 22 deletions(-) diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 459e6b66ff68..0c9120ec58ae 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -45,14 +45,24 @@ how the user addresses are used by the kernel: 1. User addresses not accessed by the kernel but used for address space management (e.g. ``mprotect()``, ``madvise()``). The use of valid - tagged pointers in this context is allowed with the exception of - ``brk()``, ``mmap()`` and the ``new_address`` argument to - ``mremap()`` as these have the potential to alias with existing - user addresses. - - NOTE: This behaviour changed in v5.6 and so some earlier kernels may - incorrectly accept valid tagged pointers for the ``brk()``, - ``mmap()`` and ``mremap()`` system calls. + tagged pointers in this context is allowed with these exceptions: + + - ``brk()``, ``mmap()`` and the ``new_address`` argument to + ``mremap()`` as these have the potential to alias with existing + user addresses. + + NOTE: This behaviour changed in v5.6 and so some earlier kernels may + incorrectly accept valid tagged pointers for the ``brk()``, + ``mmap()`` and ``mremap()`` system calls. + + - The ``range.start``, ``start`` and ``dst`` arguments to the + ``UFFDIO_*`` ``ioctl()``s used on a file descriptor obtained from + ``userfaultfd()``, as fault addresses subsequently obtained by reading + the file descriptor will be untagged, which may otherwise confuse + tag-unaware programs. + + NOTE: This behaviour changed in v5.14 and so some earlier kernels may + incorrectly accept valid tagged pointers for this system call. 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI relaxation is disabled by default and the application thread needs to diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index dd7a6c62b56f..27af6b82a758 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1236,23 +1236,21 @@ static __always_inline void wake_userfault(struct userfaultfd_ctx *ctx, } static __always_inline int validate_range(struct mm_struct *mm, - __u64 *start, __u64 len) + __u64 start, __u64 len) { __u64 task_size = mm->task_size; - *start = untagged_addr(*start); - - if (*start & ~PAGE_MASK) + if (start & ~PAGE_MASK) return -EINVAL; if (len & ~PAGE_MASK) return -EINVAL; if (!len) return -EINVAL; - if (*start < mmap_min_addr) + if (start < mmap_min_addr) return -EINVAL; - if (*start >= task_size) + if (start >= task_size) return -EINVAL; - if (len > task_size - *start) + if (len > task_size - start) return -EINVAL; return 0; } @@ -1313,7 +1311,7 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, vm_flags |= VM_UFFD_MINOR; } - ret = validate_range(mm, &uffdio_register.range.start, + ret = validate_range(mm, uffdio_register.range.start, uffdio_register.range.len); if (ret) goto out; @@ -1519,7 +1517,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_unregister, buf, sizeof(uffdio_unregister))) goto out; - ret = validate_range(mm, &uffdio_unregister.start, + ret = validate_range(mm, uffdio_unregister.start, uffdio_unregister.len); if (ret) goto out; @@ -1668,7 +1666,7 @@ static int userfaultfd_wake(struct userfaultfd_ctx *ctx, if (copy_from_user(&uffdio_wake, buf, sizeof(uffdio_wake))) goto out; - ret = validate_range(ctx->mm, &uffdio_wake.start, uffdio_wake.len); + ret = validate_range(ctx->mm, uffdio_wake.start, uffdio_wake.len); if (ret) goto out; @@ -1708,7 +1706,7 @@ static int userfaultfd_copy(struct userfaultfd_ctx *ctx, sizeof(uffdio_copy)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_copy.dst, uffdio_copy.len); + ret = validate_range(ctx->mm, uffdio_copy.dst, uffdio_copy.len); if (ret) goto out; /* @@ -1765,7 +1763,7 @@ static int userfaultfd_zeropage(struct userfaultfd_ctx *ctx, sizeof(uffdio_zeropage)-sizeof(__s64))) goto out; - ret = validate_range(ctx->mm, &uffdio_zeropage.range.start, + ret = validate_range(ctx->mm, uffdio_zeropage.range.start, uffdio_zeropage.range.len); if (ret) goto out; @@ -1815,7 +1813,7 @@ static int userfaultfd_writeprotect(struct userfaultfd_ctx *ctx, sizeof(struct uffdio_writeprotect))) return -EFAULT; - ret = validate_range(ctx->mm, &uffdio_wp.range.start, + ret = validate_range(ctx->mm, uffdio_wp.range.start, uffdio_wp.range.len); if (ret) return ret; @@ -1863,7 +1861,7 @@ static int userfaultfd_continue(struct userfaultfd_ctx *ctx, unsigned long arg) sizeof(uffdio_continue) - (sizeof(__s64)))) goto out; - ret = validate_range(ctx->mm, &uffdio_continue.range.start, + ret = validate_range(ctx->mm, uffdio_continue.range.start, uffdio_continue.range.len); if (ret) goto out; -- 2.32.0.93.g670b81a890-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel