From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B46A375AB2 for ; Sat, 9 May 2026 02:46:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778294781; cv=none; b=iKx9X+JpV2WkbKfJjlgNB5dAiCiUYtdpanbJ+zlAL0WZ9PXcjBkCJjd1SKroU61AfhACbE5YpvxhdlX0k3TNtjjznx4swLbXekrmss7pKVci2xJx8CQDIeZZzy6cohME73Yf/p78adZeVE5unlYRtwNYNC3j+eIqQ7Jli3a1oTQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778294781; c=relaxed/simple; bh=2lQvI3eWTzyJtAFOoLPchUt7vjSHRyjNBxvcylCdAgA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Pn6EKVJ0CKr9Vvy2uY4biP0zSXJQV5dgdkQuvwURwfoQ9JgVsxMwTFKlU9lO8uzQx4Z3lJ/+SfnFFc7prOvpJmcIM8Mkek93fZ6ktGgnyxKo7Vhh3gQ7q2gBU5xB0GfR+4MMO8Xv8nB0QbGMy0bQ77RQVQODPdM1HTqBNR75flg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=DKKQ1Dht; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="DKKQ1Dht" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778294780; x=1809830780; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=2lQvI3eWTzyJtAFOoLPchUt7vjSHRyjNBxvcylCdAgA=; b=DKKQ1DhtckacUUo/2GDRA/R4fa5MlBCC4pU14OlKMDGyp0lj/diEIEF+ guEXhgsiRB68R7JNrDouJwYF3Ud0LrVxaLb4sq5NYuRN89OZLOUgHNmdr SOkJ3xM5jbeHTTBvTXnH5Ce8O1j9AXLk5qzz7P4NLMeqk3nihi9Y4D9pY +N7tx1gA+fWzTL6Fko5zlzXczJ8Pfq76/5a++sv7OkWVuGvqWez1kABWk Qoz1vY8PO7SHS9vOjl/kz6XHmHwqt5snpMMhy5vEmh1VN5e8CRm2xi8gE YLufwM2srxD5EeVv2DseDZMfB5lhfKRsRKHvDgJd7gmOOQ97ueKI4FuSl Q==; X-CSE-ConnectionGUID: 2AsSmztiTZm1ReB6pngtGA== X-CSE-MsgGUID: Z7jHVvPrRteqZ2A0mHtv3A== X-IronPort-AV: E=McAfee;i="6800,10657,11780"; a="83142517" X-IronPort-AV: E=Sophos;i="6.23,224,1770624000"; d="scan'208";a="83142517" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 May 2026 19:46:20 -0700 X-CSE-ConnectionGUID: ZORUAAIgSbacym5ZotVoXA== X-CSE-MsgGUID: ym1tPgqCQ4urfGMkOcFsJw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,224,1770624000"; d="scan'208";a="236103475" Received: from allen-box.sh.intel.com ([10.239.159.52]) by orviesa010.jf.intel.com with ESMTP; 08 May 2026 19:46:18 -0700 From: Lu Baolu To: Joerg Roedel Cc: Zhenzhong Duan , =?UTF-8?q?Naval=20Alcal=C3=A1?= , iommu@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] iommu/vt-d: Avoid NULL pointer dereference or refcount corruption Date: Sat, 9 May 2026 10:43:46 +0800 Message-ID: <20260509024348.3516523-4-baolu.lu@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260509024348.3516523-1-baolu.lu@linux.intel.com> References: <20260509024348.3516523-1-baolu.lu@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Zhenzhong Duan Commit 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") fixed a NULL pointer dereference in an unlikely situation partly. If dev_pasid is not found in the dev_pasids list, it remains NULL. However, the teardown operations are executed unconditionally, this lead to a NULL pointer dereference or refcount corruption. If the domain was never attached to this IOMMU, info will be NULL, which would cause an immediate dereference when checking --info->refcnt. Even if info is not NULL, decrementing the refcount without having removed a valid PASID might unbalance the count. This could lead to premature dropping of the refcount to 0, potentially causing a use-after-free for the remaining active devices sharing the domain. Fix it by returning early if dev_pasid is NULL, before executing the teardown operations. Issue found by AI review and suggested by Kevin Tian. https://sashiko.dev/#/patchset/20260421031347.1408890-1-zhenzhong.duan%40intel.com Fixes: 60f030f7418d ("iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE") Cc: stable@vger.kernel.org Suggested-by: Kevin Tian Signed-off-by: Zhenzhong Duan Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20260422033538.95000-1-zhenzhong.duan@intel.com Signed-off-by: Lu Baolu --- drivers/iommu/intel/iommu.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index a4b123c33022..4d0e65bc131d 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3545,12 +3545,13 @@ void domain_remove_dev_pasid(struct iommu_domain *domain, } spin_unlock_irqrestore(&dmar_domain->lock, flags); + if (WARN_ON_ONCE(!dev_pasid)) + return; + cache_tag_unassign_domain(dmar_domain, dev, pasid); domain_detach_iommu(dmar_domain, iommu); - if (!WARN_ON_ONCE(!dev_pasid)) { - intel_iommu_debugfs_remove_dev_pasid(dev_pasid); - kfree(dev_pasid); - } + intel_iommu_debugfs_remove_dev_pasid(dev_pasid); + kfree(dev_pasid); } static int blocking_domain_set_dev_pasid(struct iommu_domain *domain, -- 2.43.0