All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pranjal Shrivastava <praan@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v7 5/5] iommu/vt-d: Fail probe on ATS configuration failure
Date: Mon, 1 Jun 2026 16:01:13 +0000	[thread overview]
Message-ID: <ah2syZ_FmVusREQx@google.com> (raw)
In-Reply-To: <20260601153032.36C861F00893@smtp.kernel.org>

On Mon, Jun 01, 2026 at 03:30:31PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Unconditional call to `device_rbtree_remove(info)` in the error path causes rbtree corruption for non-ATS devices.
> --
> 
> commit 73f5ec2d0aa9d509723e686b4cbf5b853c3a39c6
> Author: Pranjal Shrivastava <praan@google.com>
> 
>     iommu/vt-d: Fail probe on ATS configuration failure
>     
>     Update the Intel VT-d driver to handle ATS configuration and enablement
>     more strictly. Specifically, update the device probe to fail if
>     pci_prepare_ats() returns an error. This ensures that any ATS-capable
>     master reaching the attach phase is guaranteed to have a valid config.
> 
> > diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> > index 4d0e65bc131d7..22308e4911e1f 100644
> > --- a/drivers/iommu/intel/iommu.c
> > +++ b/drivers/iommu/intel/iommu.c
> [ ... ]
> > @@ -3288,7 +3294,10 @@ static struct iommu_device *intel_iommu_probe_device(struct device *dev)
> >  
> >  	dev_iommu_priv_set(dev, info);
> >  	if (pdev && pci_ats_supported(pdev)) {
> > -		pci_prepare_ats(pdev, VTD_PAGE_SHIFT);
> > +		ret = pci_prepare_ats(pdev, VTD_PAGE_SHIFT);
> > +		if (ret)
> > +			goto free;
> > +
> >  		ret = device_rbtree_insert(iommu, info);
> >  		if (ret)
> >  			goto free;
> 
> [Severity: High]
> This is a pre-existing issue, but does the error path in this function
> unconditionally call device_rbtree_remove() on failure, even for non-ATS
> devices?
> 
> If intel_pasid_alloc_table() fails later in intel_iommu_probe_device(), it
> jumps to clear_rbtree:
> 
>         if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) {
>                 ret = intel_pasid_alloc_table(dev);
>                 if (ret) {
>                         dev_err(dev, "PASID table allocation failed\n");
>                         goto clear_rbtree;
>                 }
> 
> clear_rbtree unconditionally removes the info from the rbtree:
> 
> clear_rbtree:
>         device_rbtree_remove(info);
> 
> Since info->node is zero-initialized via kzalloc_obj(), calling rb_erase()
> on it for a non-ATS device (which was never inserted into the rbtree) causes
> the rbtree implementation to treat it as a root node and overwrite
> iommu->device_rbtree.rb_node with NULL.
> 
> This silently destroys the entire rbtree and detaches all previously
> registered ATS devices. Could we add a check to verify if the device was
> actually inserted before calling device_rbtree_remove(info)?

All of these have already been fixed in the Intel series:
https://lore.kernel.org/all/20260531170254.60493-1-praan@google.com/

Thanks,
Praan

  reply	other threads:[~2026-06-01 16:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 14:36 [PATCH v7 0/5] iommu: Standardize ATS robustness and state tracking Pranjal Shrivastava
2026-06-01 14:36 ` [PATCH v7 1/5] PCI/ATS: Ensure pci_ats_supported() is PF-aware for VFs Pranjal Shrivastava
2026-06-03  7:25   ` Tian, Kevin
2026-06-01 14:36 ` [PATCH v7 2/5] PCI/ATS: Validate STU for VFs in pci_prepare_ats() Pranjal Shrivastava
2026-06-03  7:28   ` Tian, Kevin
2026-06-01 14:36 ` [PATCH v7 3/5] iommu/arm-smmu-v3: Fix a UAF in the probe_device error path Pranjal Shrivastava
2026-06-01 15:06   ` sashiko-bot
2026-06-03  7:31   ` Tian, Kevin
2026-06-03 13:28     ` Pranjal Shrivastava
2026-06-03 14:59       ` Jason Gunthorpe
2026-06-04  2:29         ` Baolu Lu
2026-06-04  5:22         ` Pranjal Shrivastava
2026-06-01 14:36 ` [PATCH v7 4/5] iommu/arm-smmu-v3: Standardize ATS enablement failure reporting Pranjal Shrivastava
2026-06-03  7:34   ` Tian, Kevin
2026-06-03  9:12     ` Pranjal Shrivastava
2026-06-03 10:12       ` Tian, Kevin
2026-06-01 14:36 ` [PATCH v7 5/5] iommu/vt-d: Fail probe on ATS configuration failure Pranjal Shrivastava
2026-06-01 15:30   ` sashiko-bot
2026-06-01 16:01     ` Pranjal Shrivastava [this message]
2026-06-03  5:41   ` Baolu Lu
2026-06-03  7:34   ` Tian, Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ah2syZ_FmVusREQx@google.com \
    --to=praan@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.