Re: [PATCH v2] PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] TOCTOU race leading to Use-After-Free and resource leaks via corrupted procfs pointer
--

commit cd2e3cd5b4869787fb5b78b8cfef90b55821ad2b
Author: Krzysztof Wilczyński <kwilczynski@kernel.org>

PCI/proc: Fix race between pci_proc_init() and pci_bus_add_device()

This commit attempts to fix a race condition between pci_proc_init() and
pci_bus_add_device() by lazily attaching procfs directories when buses are
created, and by protecting the device iteration in pci_proc_init() with
pci_lock_rescan_remove().

Closes: https://lore.kernel.org/linux-pci/20250702155112.40124-2-heshuan@bytedance.com/

> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> index ce36e35681e8e..a33a246ec8309 100644
> --- a/drivers/pci/proc.c
> +++ b/drivers/pci/proc.c
> @@ -416,34 +416,51 @@ static const struct seq_operations proc_bus_pci_devices_op = {
>  
>  static struct proc_dir_entry *proc_bus_pci_dir;
>  
> +int pci_proc_attach_bus(struct pci_bus *bus)
> +{
> +	char name[16];
> +
> +	if (!proc_initialized)
> +		return -EACCES;
> +
> +	if (bus->procdir)
> +		return 0;
> +
> +	if (pci_proc_domain(bus))
> +		sprintf(name, "%04x:%02x", pci_domain_nr(bus), bus->number);
> +	else
> +		sprintf(name, "%02x", bus->number);
> +
> +	bus->procdir = proc_mkdir(name, proc_bus_pci_dir);
> +	if (!bus->procdir)
> +		return -ENOMEM;

[Severity: High]
Can this direct assignment overwrite a valid pointer with NULL if a concurrent
creation fails?

If an asynchronous probe runs concurrently without holding
pci_rescan_remove_lock(), two threads might both observe bus->procdir as
NULL. If one successfully creates the entry, the second could fail due to a
name collision and return NULL, unconditionally overwriting the valid
bus->procdir.

Could this cause subsequent child devices to erroneously create their proc
files in the root of /proc?

> +
> +	return 0;
> +}
> +

[ ... ]

>  	sprintf(name, "%02x.%x", PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
> -	e = proc_create_data(name, S_IFREG | S_IRUGO | S_IWUSR, bus->procdir,
> -			     &proc_bus_pci_ops, dev);
> -	if (!e)
> +	dev->procent = proc_create_data(name, S_IFREG | S_IRUGO | S_IWUSR,
> +					dev->bus->procdir, &proc_bus_pci_ops,
> +					dev);
> +	if (!dev->procent)
>  		return -ENOMEM;

[Severity: High]
Does this assignment introduce a risk of a use-after-free and resource leak?

Similar to the bus directory, if concurrent threads call
pci_proc_attach_device() for the same device, one might overwrite a
valid dev->procent with NULL when proc_create_data() fails.

Later, pci_proc_detach_device() would call proc_remove(NULL) which does
nothing. The procfs file would be leaked, and because the file's data points
to the freed pci_dev struct, subsequent reads from userspace could trigger a
use-after-free.

> -	proc_set_size(e, dev->cfg_size);
> -	dev->procent = e;
> +	proc_set_size(dev->procent, dev->cfg_size);
>  
>  	return 0;
>  }

[ ... ]

>  static int __init pci_proc_init(void)
>  {
>  	struct pci_dev *dev = NULL;
> +
>  	proc_bus_pci_dir = proc_mkdir("bus/pci", NULL);
>  	proc_create_seq("devices", 0, proc_bus_pci_dir,
> -		    &proc_bus_pci_devices_op);
> +			&proc_bus_pci_devices_op);
> +
>  	proc_initialized = 1;
> +
> +	pci_lock_rescan_remove();
>  	for_each_pci_dev(dev)
>  		pci_proc_attach_device(dev);
> +	pci_unlock_rescan_remove();

[Severity: High]
Is this lock sufficient to serialize against lockless async probe paths?

Paths like the VMD driver (vmd_probe() -> vmd_enable_domain() ->
pci_bus_add_devices()) or platform drivers can run asynchronously and do not
always hold pci_rescan_remove_lock().

If an asynchronous probe adds devices to the global pci_bus_type list before
calling pci_proc_attach_device(), and pci_proc_init() iterates the list
under the lock, could both threads still find the new devices and call
pci_proc_attach_device() concurrently?

>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606170146.673140-1-kwilczynski@kernel.org?part=1