Re: [PATCH v21 3/4] PCI: Fail FLR when config space is inaccessible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Un-ratelimited pci_warn() in pci_dev_config_accessible() allows an attacker to flood the host kernel log.
- [High] Early bailout in pcie_flr() when config space is inaccessible skips the Function Level Reset and the subsequent wait, allowing device assignment to continue without reset, leaking state.
--

commit ce2804b7f0c0409f73465726275859a70fa16be3
Author: Farhan Ali <alifm@linux.ibm.com>

PCI: Fail FLR when config space is inaccessible

This commit adds a check to validate if a device's config space is
accessible before attempting a Function Level Reset (FLR). If the
device is in an error state and inaccessible, the reset returns early.

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e8d7de77241a6..9a9d021301c4e 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4384,6 +4384,9 @@ int pcie_flr(struct pci_dev *dev)
>  {
>  	int ret;
>  
> +	if (!pci_dev_config_accessible(dev, "FLR"))
> +		return -ENOTTY;
> +

[Severity: High]
If a device is momentarily unresponsive and this check returns -ENOTTY
immediately, doesn't this skip the FLR entirely?

Since VFIO's vfio_pci_core_enable() allows assignment to continue if a reset
returns -ENOTTY (by setting vdev->reset_works = false), could a malicious
guest intentionally put the device into an unresponsive state to bypass the
reset and leak device state to the next user?

The previous code path waited before issuing the FLR, but this early return
removes the grace period.

[Severity: High]
Because this early return bypasses the previous delay loop, can a userspace
process spam the VFIO_DEVICE_RESET ioctl in a tight loop?

If the device's config space reads ~0, pci_dev_config_accessible() prints a
warning:

drivers/pci/pci.c:pci_dev_config_accessible() {
	...
	if (PCI_POSSIBLE_ERROR(val)) {
		pci_warn(dev, "Device config space inaccessible; unable to %s\n",
				msg);
		return false;
	}
	...
}

Since this warning is unconditional and not rate-limited, could this tight
loop allow an attacker to trivially flood the host's kernel log?

>  	if (!pci_wait_for_pending_transaction(dev))
>  		pci_err(dev, "timed out waiting for pending transaction; performing function level reset anyway\n");
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630164807.643-1-alifm@linux.ibm.com?part=3