From patchwork Mon Oct 24 11:32:57 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 9338 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp466622wru; Mon, 24 Oct 2022 06:55:34 -0700 (PDT) X-Google-Smtp-Source: AMsMyM70Tvgo91AxSkXcXoysdPSZLKhJU/7hYw4BbxG1jBB5saJe7khxdlwLqvXFNlOzGGBG7YqP X-Received: by 2002:a17:90b:3847:b0:20d:c41f:de7a with SMTP id nl7-20020a17090b384700b0020dc41fde7amr57776605pjb.85.1666619724370; Mon, 24 Oct 2022 06:55:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666619724; cv=none; d=google.com; s=arc-20160816; b=iWqmR04FcCo+Ebf6hDRDwK+FF/FBAMsIvL+KyJabPe5PRzo9DXkW5SjMN12KN5esXH gIhTg4eLmRkHYNmd2C6SsbJ5Uax3PW2fx7AN5CUtCSFLJHNgbGcHAo2PB5dUC4GjovNv GeySQ4VVQpNJXQOtVwC2TDRMX27zksW1Rk1XOni/tpRIhZRGNTdSygXktHDrWA2YWgrQ g0iddcmuV6+mwgDfwcimcYstIQf6vJ1FSzZCBVdUlhaPv9yKsG2tUl1xsOpFGz3bZqA3 JwCE/HccM0Mp6438MNjqbiqC3llRLRqQU8ya8yhaXhpkL7QFf2o1LrpTmAZrP0MAev7m 1P3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=2CKumIkUn46bVun7DLRVRENHyrRRRsI0SReBmtrzcdU=; b=Rgw46ykd8h6lOYVRFd0bBTZcCLa6H9haG3zLb2U0yPKr0vVFXS4i2Y8wpOpTpcrlYZ ZGNbzEzrC3O5eyaP/QJfk+ph/FL+1bzQJrPXAOsa911IzWR1bv6KwSbfBo6txRZrIg3L W/541SqjHlB6XIiKTXq8Kj9PFZuVY0LLUSSryBAxEV0XtBHVigvZnC6FxBnicMPhPU8K +R5yTZhhMzWmTQH9kZdUFwvs3mvjP14ja1eaw3pghzkj5NzX8sU7wHQAqRaEKzCcXTJj f7Uw4UxarOnk/iNnbzxNEHvMlSBn+UC2Fb5QD5ww2s+mWMlfkxiGOAXWRRyLpkHzwEOq 8UuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=K+mDlLyy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t8-20020a634608000000b00461d9cce57dsi12155991pga.254.2022.10.24.06.55.07; Mon, 24 Oct 2022 06:55:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=K+mDlLyy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236643AbiJXNxz (ORCPT + 99 others); Mon, 24 Oct 2022 09:53:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236553AbiJXNw7 (ORCPT ); Mon, 24 Oct 2022 09:52:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21F42BC44D; Mon, 24 Oct 2022 05:43:13 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C45E76133D; Mon, 24 Oct 2022 12:32:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B085CC433C1; Mon, 24 Oct 2022 12:32:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1666614754; bh=bNzgAFP22hNtf2DtuINAlIo+vZoacqJSXYftjrlrzFk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K+mDlLyy5qRs1OMuDQwYw/+Qr5LzHWFRHYQ9q8WVMdYFLfSRu8Y2QygYsP4lIYitu 5n46cNNWm01yksq2dEAQsvi/LzcYgYFIu6YEf8RI4B4hOVMkfeHQWdLsCF4OUZ12Xe SrJrgJumyiAogfy/LyBkvF2TyITzh+HX8IQXCsdE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Liu Shixin , Kefeng Wang , syzbot+193f9cee8638750b23cf@syzkaller.appspotmail.com, Liu Zixian , Mike Kravetz , David Hildenbrand , John Hubbard , Muchun Song , Sidhartha Kumar , Andrew Morton Subject: [PATCH 5.10 380/390] mm: hugetlb: fix UAF in hugetlb_handle_userfault Date: Mon, 24 Oct 2022 13:32:57 +0200 Message-Id: <20221024113039.156393036@linuxfoundation.org> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221024113022.510008560@linuxfoundation.org> References: <20221024113022.510008560@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747577444150077638?= X-GMAIL-MSGID: =?utf-8?q?1747577444150077638?= From: Liu Shixin commit 958f32ce832ba781ac20e11bb2d12a9352ea28fc upstream. The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ Link: https://lkml.kernel.org/r/20220923042113.137273-1-liushixin2@huawei.com Fixes: 1a1aad8a9b7b ("userfaultfd: hugetlbfs: add userfaultfd hugetlb hook") Signed-off-by: Liu Shixin Signed-off-by: Kefeng Wang Reported-by: syzbot+193f9cee8638750b23cf@syzkaller.appspotmail.com Reported-by: Liu Zixian Reviewed-by: Mike Kravetz Cc: David Hildenbrand Cc: John Hubbard Cc: Muchun Song Cc: Sidhartha Kumar Cc: [4.14+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- mm/hugetlb.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -4337,6 +4337,7 @@ static vm_fault_t hugetlb_no_page(struct spinlock_t *ptl; unsigned long haddr = address & huge_page_mask(h); bool new_page = false; + u32 hash = hugetlb_fault_mutex_hash(mapping, idx); /* * Currently, we are forced to kill the process in the event the @@ -4346,7 +4347,7 @@ static vm_fault_t hugetlb_no_page(struct if (is_vma_resv_set(vma, HPAGE_RESV_UNMAPPED)) { pr_warn_ratelimited("PID %d killed due to inadequate hugepage pool\n", current->pid); - return ret; + goto out; } /* @@ -4365,7 +4366,6 @@ retry: * Check for page in userfault range */ if (userfaultfd_missing(vma)) { - u32 hash; struct vm_fault vmf = { .vma = vma, .address = haddr, @@ -4380,17 +4380,14 @@ retry: }; /* - * hugetlb_fault_mutex and i_mmap_rwsem must be - * dropped before handling userfault. Reacquire - * after handling fault to make calling code simpler. + * vma_lock and hugetlb_fault_mutex must be dropped + * before handling userfault. Also mmap_lock will + * be dropped during handling userfault, any vma + * operation should be careful from here. */ - hash = hugetlb_fault_mutex_hash(mapping, idx); mutex_unlock(&hugetlb_fault_mutex_table[hash]); i_mmap_unlock_read(mapping); - ret = handle_userfault(&vmf, VM_UFFD_MISSING); - i_mmap_lock_read(mapping); - mutex_lock(&hugetlb_fault_mutex_table[hash]); - goto out; + return handle_userfault(&vmf, VM_UFFD_MISSING); } page = alloc_huge_page(vma, haddr, 0); @@ -4497,6 +4494,8 @@ retry: unlock_page(page); out: + mutex_unlock(&hugetlb_fault_mutex_table[hash]); + i_mmap_unlock_read(mapping); return ret; backout: @@ -4592,10 +4591,12 @@ vm_fault_t hugetlb_fault(struct mm_struc mutex_lock(&hugetlb_fault_mutex_table[hash]); entry = huge_ptep_get(ptep); - if (huge_pte_none(entry)) { - ret = hugetlb_no_page(mm, vma, mapping, idx, address, ptep, flags); - goto out_mutex; - } + if (huge_pte_none(entry)) + /* + * hugetlb_no_page will drop vma lock and hugetlb fault + * mutex internally, which make us return immediately. + */ + return hugetlb_no_page(mm, vma, mapping, idx, address, ptep, flags); ret = 0;