Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp982915pxb; Fri, 15 Apr 2022 17:22:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/ufS1pqSPfv7JXvSiZHYBAdYSZDqQyuU7DbrDNz+b6jIT95ZJSjtt2QWMjGKRSEiAgPbP X-Received: by 2002:a05:6a00:24cf:b0:505:d9fd:e415 with SMTP id d15-20020a056a0024cf00b00505d9fde415mr1289720pfv.78.1650068528220; Fri, 15 Apr 2022 17:22:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650068528; cv=none; d=google.com; s=arc-20160816; b=dqPz/+sfnTZC+53HMKopen8viMwUGhRNGeseAZVJbrIB7k2hH90tW1OPWjCGylKHk1 08vkrF3ULSprcv5x14hf/nPH3HX993Ffk3c9xHqKIS0ViIi271IgPp7nX9avSr4010F2 7b4T5LEFHSpepPWoCL9+MQEWG/A2v4B35IsWmdKEV+697xLwNra7aIY0OrmR3AJBbJkm +zTm63S9iNaKovidgRmlfh/7fQ2sdv57DygpL1cU3POjSP5PVdWYdpe0e98TTrvXrCcN e+9dfhmLJTJceRK6IFtJNL8Zc/R14VP5mbqpU0OETU8LmknTmYW0NY70gDi+a0np/Tjf P6oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Yw+goJhiHAh7neUQsbQW5L5Lubu6eDosqxZxTiTLAgw=; b=txJR9wWNJpMBrn+rUNlDfdkaU9F67mk2dWwrmfpN3mIfEJSgwJQIEHS4TbgUrg4S4x MDqFJ7A/AuemaltzJ8IJZPi35+llyiGDZb7K0AgKlmzlixUgu9oO+2urBlDwO4H65fvE CP5Z31Z3oJlQrFfZNcdPQj045sYgfy+p4KR3ocPGSn3y15seY3niOtsB6/ZCmz5B0wFq lymK0x3l6KEmlWWG3PHkgOMM+UJKLGDs/wYVEh+BIdhjm5WAcWDbXzTSkBxnJKnrJ0Mw DWyCCdzgNH6ifKqOLJspxTRLFU+jeYbeyCZk1sB2Dal+LO4g3wHvpWa3EE6ON/gPeB5F IWQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hvEqWuLe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id y12-20020a170902864c00b0015415173078si2249975plt.220.2022.04.15.17.22.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Apr 2022 17:22:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=hvEqWuLe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E3E29D5EA9; Fri, 15 Apr 2022 17:20:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351783AbiDOJxN (ORCPT + 99 others); Fri, 15 Apr 2022 05:53:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51232 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236399AbiDOJxK (ORCPT ); Fri, 15 Apr 2022 05:53:10 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4248B6E6B for ; Fri, 15 Apr 2022 02:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650016242; x=1681552242; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=k0+BB6ioS9sg4ZQkLIJuljI7na5dCngyl54RvX7fbN8=; b=hvEqWuLeRQ5mjL3060IaVYT6YPp2x6jdINCBQrCyJQzBFuH0wxOBg3CN 9hha7IJ49RjtxnQd2AeZhPRUxZF9AnbmtImAOvuzPHQEdEEDqFbTlnMZ9 m+UjVL63mmdDImm3JgQAIJ1KsrXxPQ8iYgJw745aseoNfXG50/xtSSkJE OuJ2pR9MqkABWOMmBALQBH1oXpjHs95E8QHuQy/coL+pcsAppkk0JvUsb ram+ASwu9H8GvEZFs37zKDx+lvlMpnC4a/zc3ADdCN0OqFbX/4yzd9nue 4XQsmHIjqZ5XkSn/SE7dd2uLhyhuJqkKTT57YP+BPTpx6veSuR5ebpasy A==; X-IronPort-AV: E=McAfee;i="6400,9594,10317"; a="262883274" X-IronPort-AV: E=Sophos;i="5.90,262,1643702400"; d="scan'208";a="262883274" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 02:50:42 -0700 X-IronPort-AV: E=Sophos;i="5.90,262,1643702400"; d="scan'208";a="553089696" Received: from fyu1.sc.intel.com ([172.25.103.126]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2022 02:50:41 -0700 Date: Fri, 15 Apr 2022 02:51:08 -0700 From: Fenghua Yu To: "zhangfei.gao@foxmail.com" Cc: Dave Hansen , Joerg Roedel , jean-philippe , Ravi V Shankar , Tony Luck , Ashok Raj , Peter Zijlstra , Dave Hansen , x86 , linux-kernel , iommu , Ingo Molnar , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Thomas Gleixner Subject: Re: [PATCH v4 05/11] iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit Message-ID: References: <56ed509d-a7cf-1fde-676c-a28eb204989b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 On Thu, Apr 14, 2022 at 06:08:09PM +0800, zhangfei.gao@foxmail.com wrote: > > On 2022/4/12 下午11:35, zhangfei.gao@foxmail.com wrote: > > Hi, Fenghua > > > > On 2022/4/12 下午9:41, Fenghua Yu wrote: > > > Hi, Zhangfei, > > > > > > On Tue, Apr 12, 2022 at 03:04:09PM +0800, zhangfei.gao@foxmail.com > > > wrote: > > > > > > > > On 2022/4/11 下午10:52, Dave Hansen wrote: > > > > > On 4/11/22 07:44, zhangfei.gao@foxmail.com wrote: > > > > > > On 2022/4/11 下午10:36, Dave Hansen wrote: > > > > > > > On 4/11/22 07:20, zhangfei.gao@foxmail.com wrote: > > Agree with Dave, I think user space should not be broken. > > > > Thanks > > Any plan about this regression? > Currently I need this patch to workaround the issue. > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > index 22ddd05bbdcd..2d74ac53d11c 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c > @@ -4,6 +4,7 @@ >   */ > >  #include > +#include >  #include >  #include >  #include > @@ -363,6 +364,7 @@ arm_smmu_sva_bind(struct device *dev, struct mm_struct > *mm, void *drvdata) > >         mutex_lock(&sva_lock); >         handle = __arm_smmu_sva_bind(dev, mm); > +       mmget(mm); >         mutex_unlock(&sva_lock); >         return handle; >  } > @@ -377,6 +379,7 @@ void arm_smmu_sva_unbind(struct iommu_sva *handle) >                 arm_smmu_mmu_notifier_put(bond->smmu_mn); >                 kfree(bond); >         } > +       mmput(bond->mm); >         mutex_unlock(&sva_lock); >  } Could you please review and/or test this patch? It's supposed to fix the PASID issue on both ARM and X86. From a6444e1e5bd8076f5e5c5e950d3192de327f0c9c Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Fri, 15 Apr 2022 00:51:33 -0700 Subject: [RFC PATCH] iommu/sva: Fix PASID use-after-free issue A PASID might be still used even though it is freed on mm exit. process A: sva_bind(); ioasid_alloc() = N; // Get PASID N for the mm fork(): // spawn process B exit(); ioasid_free(N); process B: device uses PASID N -> failure sva_unbind(); Dave Hansen suggests to take a refcount on the mm whenever binding the PASID to a device and drop the refcount on unbinding. The mm won't be dropped if the PASID is still bound to it. Fixes: 701fac40384f ("iommu/sva: Assign a PASID to mm on PASID allocation and free it on mm exit") Reported-by: Zhangfei Gao Suggested-by: Dave Hansen" Signed-off-by: Fenghua Yu --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 6 ++++++ drivers/iommu/intel/svm.c | 4 ++++ 2 files changed, 10 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c index 22ddd05bbdcd..3fcb842a0df0 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c @@ -7,6 +7,7 @@ #include #include #include +#include #include "arm-smmu-v3.h" #include "../../iommu-sva-lib.h" @@ -363,6 +364,9 @@ arm_smmu_sva_bind(struct device *dev, struct mm_struct *mm, void *drvdata) mutex_lock(&sva_lock); handle = __arm_smmu_sva_bind(dev, mm); + /* Take an mm refcount on a successful bind. */ + if (!IS_ERR(handle)) + mmget(mm); mutex_unlock(&sva_lock); return handle; } @@ -372,6 +376,8 @@ void arm_smmu_sva_unbind(struct iommu_sva *handle) struct arm_smmu_bond *bond = sva_to_bond(handle); mutex_lock(&sva_lock); + /* Drop an mm refcount. */ + mmput(bond->mm); if (refcount_dec_and_test(&bond->refs)) { list_del(&bond->list); arm_smmu_mmu_notifier_put(bond->smmu_mn); diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index 23a38763c1d1..345a0d5d7922 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -403,6 +403,8 @@ static struct iommu_sva *intel_svm_bind_mm(struct intel_iommu *iommu, goto free_sdev; list_add_rcu(&sdev->list, &svm->devs); + /* Take an mm refcount on binding mm. */ + mmget(mm); success: return &sdev->sva; @@ -465,6 +467,8 @@ static int intel_svm_unbind_mm(struct device *dev, u32 pasid) kfree(svm); } } + /* Drop an mm reference on unbinding mm. */ + mmput(mm); } out: return ret; -- 2.32.0