From: sashiko-bot@kernel.org
To: "Farhan Ali" <alifm@linux.ibm.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v17 1/7] PCI: Allow per function PCI slots to fix slot reset on s390
Date: Wed, 20 May 2026 17:44:48 +0000 [thread overview]
Message-ID: <20260520174448.C20FD1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260520171113.1111-2-alifm@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Lockless access and double-dereference of `dev->slot` in `pci_dev_reset_slot_function()` can lead to a TOCTOU race resulting in a Use-After-Free or NULL pointer dereference.
--
commit 3e69d6bfb3fdb198ceb79bc29354354788895096
Author: Farhan Ali <alifm@linux.ibm.com>
PCI: Allow per function PCI slots to fix slot reset on s390
This commit introduces a per_func_slot flag to struct pci_slot to allow
per-function PCI slots for functions managed through a hypervisor, such as on
s390. It modifies slot matching logic and pci_dev_reset_slot_function() to
account for this new behavior.
[ ... ]
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8f7cfcc000901..d0c9f0166af5c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4865,8 +4865,9 @@ static int pci_reset_hotplug_slot(struct hotplug_slot *hotplug, bool probe)
>
> static int pci_dev_reset_slot_function(struct pci_dev *dev, bool probe)
> {
> - if (dev->multifunction || dev->subordinate || !dev->slot ||
> - dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)
> + if (dev->subordinate || !dev->slot ||
> + dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
> + (dev->multifunction && !dev->slot->per_func_slot))
[Severity: High]
This is a pre-existing issue, but does this lockless access to dev->slot
introduce a time-of-check to time-of-use race condition?
Because dev->slot is read without holding pci_slot_mutex or device_lock(),
a concurrent hotplug removal could clear dev->slot and free the slot
structure in pci_slot_release() while this code is running.
If the compiler reloads the pointer after the !dev->slot check, or if the
pointer is kept in a register while the memory is freed, could accessing
dev->slot->per_func_slot or dev->slot->hotplug below result in a null pointer
dereference or use-after-free?
> return -ENOTTY;
>
> return pci_reset_hotplug_slot(dev->slot->hotplug, probe);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260520171113.1111-1-alifm@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-05-20 17:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 17:11 [PATCH v17 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
2026-05-20 17:11 ` [PATCH v17 1/7] PCI: Allow per function PCI slots to fix slot reset on s390 Farhan Ali
2026-05-20 17:44 ` sashiko-bot [this message]
2026-05-20 17:11 ` [PATCH v17 2/7] PCI: Avoid saving config space state if inaccessible Farhan Ali
2026-05-20 18:21 ` sashiko-bot
2026-05-20 17:11 ` [PATCH v17 3/7] PCI: Fail FLR when config space is inaccessible Farhan Ali
2026-05-20 17:11 ` [PATCH v17 4/7] s390/pci: Store PCI error information for passthrough devices Farhan Ali
2026-05-20 19:41 ` Niklas Schnelle
2026-05-20 17:11 ` [PATCH v17 5/7] vfio-pci/zdev: Add a device feature for error information Farhan Ali
2026-05-20 19:59 ` sashiko-bot
2026-06-02 20:32 ` Alex Williamson
2026-06-02 21:38 ` Farhan Ali
2026-06-02 22:33 ` Alex Williamson
2026-05-20 17:11 ` [PATCH v17 6/7] vfio/pci: Add a reset_done callback for vfio-pci driver Farhan Ali
2026-05-20 20:40 ` sashiko-bot
2026-05-20 17:11 ` [PATCH v17 7/7] vfio/pci: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX Farhan Ali
2026-06-01 16:47 ` [PATCH v17 0/7] Error recovery for vfio-pci devices on s390x Farhan Ali
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=20260520174448.C20FD1F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alifm@linux.ibm.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.