From patchwork Thu Jul 20 01:32:49 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jann Horn X-Patchwork-Id: 13319698 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90E06C001B0 for ; Thu, 20 Jul 2023 01:33:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 180652800A5; Wed, 19 Jul 2023 21:33:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1318328004C; Wed, 19 Jul 2023 21:33:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3B602800A5; Wed, 19 Jul 2023 21:33:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E48ED28004C for ; Wed, 19 Jul 2023 21:33:07 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AE1D2C04FD for ; Thu, 20 Jul 2023 01:33:07 +0000 (UTC) X-FDA: 81030266814.17.148AEE5 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf05.hostedemail.com (Postfix) with ESMTP id D647E10000C for ; Thu, 20 Jul 2023 01:33:05 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WXjrMbr9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689816785; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=axi8/ydXGpVdXXhaXsUkDkCMMEYa0OL+dOx0IDR8aaE=; b=wZX3PBtK1xy7WXy3ECdVEaj2k8Z7psnUaF709HA7pKgDUVYOZIouVI2nJTGsmDz0kpbBfQ tnUycnlaiLlf+jCQwDm8JvQ2lZG5AkjjCrDYtDx0bUqzXQiQtU+7kL29pCh8PndsmU0gqU 98kvnmyl4MDIcP+W5vE9vXK0R3iwVcI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WXjrMbr9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of jannh@google.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689816785; a=rsa-sha256; cv=none; b=nD16a6T7PIPFXo1wtt2/ywYHB4iFnwWslGEWxLVBHlwBG1ndtKFOVJz4ogC0jYT6/WFqjZ 2iPIxQge1UgVNe4yCUEqpeZ3e6KWsSF0yx0GBp3cf6zygYdm23glxwzBZ+lL3BL7laq9dj QEGFpFJ1Aw/XsQFo5fAGKtG1Vfl3Rp8= Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-3fbd200d354so21945e9.1 for ; Wed, 19 Jul 2023 18:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689816784; x=1690421584; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=axi8/ydXGpVdXXhaXsUkDkCMMEYa0OL+dOx0IDR8aaE=; b=WXjrMbr9atquLfOw+cjpQSkzNcjeB8WcdPo7aPf/kY5i5sKJkjlYf9saHwOWOiMmp9 d1lPJf7sKH1qXAQe5SvE7AzwVa9EKBIB7d8a6b/h+2znx182BUQV+XrCbeQukmVZWAGG EK+ngylAIFNJKreIW8IXx3skMmCKmQ/BsesYnF5Gf+6AIran2pP58gigVzi7UJ0ZyWY9 56mzVIg8dVxIxYxRaFO8+6VmNcDPZmjgDmbnGPhruQ7QW0gfRTRnhJ8wtGc3UXmJMPP7 g+aGIt/gNTJFGDVNRTs7KTVm6MZ0wyn6JgtV4eGg/b6EBhpbkNju1t3sz59OHAqB3nmF SNpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689816784; x=1690421584; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=axi8/ydXGpVdXXhaXsUkDkCMMEYa0OL+dOx0IDR8aaE=; b=VdGLqWL6DrtRdvO9xBsH369MgbTE0ve5OJ0v7OJrRV2xjG4QwAgONfO/nYwfSUSgFA X+XmuebAAJv5yO4UYz+assV4g8vFKErKc4f5tRkNZvTQ6KJ+ktnycJytmeH/eV9y3YNB A/urbUeILfch89SgQfgSfEywL8w7NEPLLjhlrxdYiqgv5MUUngAzR+iWQSonm4iWO15D ACrsBm6FjTXAjBzy4uAZolUWeyPC4Wza1T1cEhXCXVy9H6O3sgNhiPCmmFqkyrcezlwd S7hd0qQECaGMSHSyauy+pSVi+TwnAV8YxLrhYgZ9fgQEQ2Jv8ZEYEIZftmy+PaLrXjb0 0kDg== X-Gm-Message-State: ABy/qLaD/dbn/98v50I0Qzz6XyKrqzxorTExcWSMRpTdE8fKTObbH5Ye V2FWMfWtZUbDW2XikIrfrgLHig== X-Google-Smtp-Source: APBJJlFAX20Favw69oaawKb8T42JtB/oQ/U0QzgvZR+zGnkhN/R/v8l4DvPE15vHFI6zzTYVkUHMjw== X-Received: by 2002:a05:600c:3d95:b0:3f7:3e85:36a with SMTP id bi21-20020a05600c3d9500b003f73e85036amr32366wmb.7.1689816784258; Wed, 19 Jul 2023 18:33:04 -0700 (PDT) Received: from localhost ([2a00:79e0:9d:4:5d60:25da:5b42:67a3]) by smtp.gmail.com with ESMTPSA id c7-20020adfe747000000b003143c9beeaesm6625099wrn.44.2023.07.19.18.33.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 18:33:03 -0700 (PDT) From: Jann Horn To: Andrew Morton Cc: Suren Baghdasaryan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm: Don't drop VMA locks in mm_drop_all_locks() Date: Thu, 20 Jul 2023 03:32:49 +0200 Message-ID: <20230720013249.199981-1-jannh@google.com> X-Mailer: git-send-email 2.41.0.255.g8b1d071c50-goog MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: pgptoumxfg86uwmamon9x56zjkjb664h X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D647E10000C X-HE-Tag: 1689816785-253324 X-HE-Meta: U2FsdGVkX187vCF0Ii1Tkfvnv3c0wiWNnxSsNreQkpT/3zLjrf1MigxmpjWwmcZuOkqs9ZgyCYUWY2ZMHrF4uhQm6W3yRQvffg8qDX+DnHdTP6+PnWQSMzWE3xINRTrfhF/eBxReZWRdlenlnZ2eSDNK0BpqtlrLorgq/7cwELtN8ZmyOqnHqc4rJP6Fv+bdGdokrdxMkd7kRWl8Xw/lXIre5RVAIRPVJU6yhcOzE2hj1hhaq+I+KwjX7yUtRbrZBuVNVUe1BjKL4DHjQm7w18ttQ1AIa3V4Njcb2+f0vZXokXlqfQzjUR+xKieKIQQI08vaeOqQOWRrDV4dX1SQJFsxemCl1XuD8Fl+HpXfarCHPR/57GWQpTMkf/XYUoGsXskXfjCHFewv+2IGw7VCGiuazHzcjkyOS3Tbr7zZcPSbTEzm3sQn7a43NTRGV0svV91RSqgKZjHyovSBc5LPVyV4BaTlIJsFI2HmADUpR7lCP0u7n5/RBzrpPvNuSfSS8Ou7a09lBqxhTKuaxAeTHur9G0b9zehFf588g2C++F8VhiFp552wLuvEYz7NULKwd0+XhiD8zqp6poV8dEx/RTLcY82gCEmhej/D7mJLnF9RVy4ne00xPSF/eVJ2NiWC4WFc2o7VDeBSHVolYfIxknjsAYb9b48kO90lEo1WKaACZiHv6gaxOfToYtdgQC+o55TzkKF3FULz14IUCXSCgLvDaFhyHbAGpZxlJ8zsoLIDY6HxxsgDmmy82svaSU9Y5yhVKYbd1mjepTbWf5lMs5/VE8LzVF/fJTtTtxxHNmW7HfLk982kTJ1vIlOjogEPmP5aa2brg+jvDpXhE2ps8Nbek08O8UaseXwHij3q1v/uUDoOXFmbhXKl+qmJfbvp3RQW93+tirzGxx0PPbPm7VDd+i9woGR0+zyhPOpMTS+X59rtR3xfOzH+NDoiYxOMXLb6wb9Z8mIVOWaYaCd Mxi6y1IG 1cwBW2hg73y6nCCkwU8kL1lRIKDlDUindKVnCMW7LVZO6Q9namz1Sq6ytZ2M/A1lanEi/kwEX15Y6wkmInHVASHtPeXhEacrv4SPZ9OUcIsNVNbq+CFgnjtTjsqv3q47qhw+y7bOIT4T9fe8J5b7nXnVLc2aGNO6iiQBBqWkSP0GIub1CsrJ2wszUGM+/DetOl3q4K170lJtR4GAK05q7e3d+yHEmxxsSdvJrC4syu7BOfbcSsgdaVsAATYYA+8qkV6bfFgDEP32ZoZ9qk4gO3ixNeayiWy7TwcYrGK9mXROQW+zhh5TBfib6QfZdERaEfrWZ2dk3Zzdr7iihbtUWUydU5JfHdwrXWplKOQc7eYB2Nhmn+wFl/zsJEGFVi6WzgkoITrRUchwLKhX5vCeXiTAAMxQokbYbTZ+4dZAGwU8p+rM= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003530, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Despite its name, mm_drop_all_locks() does not drop _all_ locks; the mmap lock is held write-locked by the caller, and the caller is responsible for dropping the mmap lock at a later point (which will also release the VMA locks). Calling vma_end_write_all() here is dangerous because the caller might have write-locked a VMA with the expectation that it will stay write-locked until the mmap_lock is released, as usual. This _almost_ becomes a problem in the following scenario: An anonymous VMA A and an SGX VMA B are mapped adjacent to each other. Userspace calls munmap() on a range starting at the start address of A and ending in the middle of B. Hypothetical call graph with additional notes in brackets: do_vmi_align_munmap [begin first for_each_vma_range loop] vma_start_write [on VMA A] vma_mark_detached [on VMA A] __split_vma [on VMA B] sgx_vma_open [== new->vm_ops->open] sgx_encl_mm_add __mmu_notifier_register [luckily THIS CAN'T ACTUALLY HAPPEN] mm_take_all_locks mm_drop_all_locks vma_end_write_all [drops VMA lock taken on VMA A before] vma_start_write [on VMA B] vma_mark_detached [on VMA B] [end first for_each_vma_range loop] vma_iter_clear_gfp [removes VMAs from maple tree] mmap_write_downgrade unmap_region mmap_read_unlock In this hypothetical scenario, while do_vmi_align_munmap() thinks it still holds a VMA write lock on VMA A, the VMA write lock has actually been invalidated inside __split_vma(). The call from sgx_encl_mm_add() to __mmu_notifier_register() can't actually happen here, as far as I understand, because we are duplicating an existing SGX VMA, but sgx_encl_mm_add() only calls __mmu_notifier_register() for the first SGX VMA created in a given process. So this could only happen in fork(), not on munmap(). But in my view it is just pure luck that this can't happen. Also, we wouldn't actually have any bad consequences from this in do_vmi_align_munmap(), because by the time the bug drops the lock on VMA A, we've already marked VMA A as detached, which makes it completely ineligible for any VMA-locked page faults. But again, that's just pure luck. So remove the vma_end_write_all(), so that VMA write locks are only ever released on mmap_write_unlock() or mmap_write_downgrade(). Fixes: eeff9a5d47f8 ("mm/mmap: prevent pagefault handler from racing with mmu_notifier registration") Cc: Suren Baghdasaryan Signed-off-by: Jann Horn Reviewed-by: Suren Baghdasaryan --- mm/mmap.c | 1 - 1 file changed, 1 deletion(-) base-commit: bfa3037d828050896ae52f6467b6ca2489ae6fb1 diff --git a/mm/mmap.c b/mm/mmap.c index 3eda23c9ebe7..1ff354b1e23c 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -3758,7 +3758,6 @@ void mm_drop_all_locks(struct mm_struct *mm) if (vma->vm_file && vma->vm_file->f_mapping) vm_unlock_mapping(vma->vm_file->f_mapping); } - vma_end_write_all(mm); mutex_unlock(&mm_all_locks_mutex); }