Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ziming Du" <duziming2@huawei.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v2 2/6] PCI/proc: Serialize config inode size updates
Date: Thu, 30 Jul 2026 03:13:39 +0000	[thread overview]
Message-ID: <20260730031339.AE6D11F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260730032438.1643450-3-duziming2@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The return values of `__get_user()` and `__put_user()` are silently ignored, risking hardware configuration corruption and silent failures on page faults.
--

--- Patch [2]: [PATCH v2 2/6] PCI/proc: Serialize config inode size updates ---
commit 3aca0ed476ea2dd3079bd4be2a68be7793fdde7b
Author: Ziming Du <duziming2@huawei.com>

PCI/proc: Serialize config inode size updates

proc_bus_pci_write() calls i_size_write() without serializing concurrent
writers. On 32-bit SMP systems, concurrent updates can corrupt
i_size_seqcount and make later i_size_read() calls spin indefinitely.
This patch protects the inode size update with the inode lock.

> diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> index cad749924dd89..ec2338c1e667e 100644
> --- a/drivers/pci/proc.c
> +++ b/drivers/pci/proc.c
> @@ -181,7 +181,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,
>  	pci_config_pm_runtime_put(dev);
>  
>  	*ppos = pos;
> +	inode_lock(ino);
>  	i_size_write(ino, dev->cfg_size);

[Severity: High]
This isn't a bug introduced by this patch, but looking at
proc_bus_pci_write() earlier in this function, the return value of
__get_user() is silently ignored:

drivers/pci/proc.c:proc_bus_pci_write() {
	...
	if ((off & 1) && size) {
		unsigned char val;
		__get_user(val, buf);
		pci_user_write_config_byte(dev, off, val);
	...
}

Does this code fail to handle page faults correctly?

If a process calls write() with a buffer that fails memory access,
__get_user() sets the target variable to zero and returns -EFAULT.
Because this return value is ignored, the kernel proceeds to write these
uninitialized zeroes directly into the PCI device's configuration space.

Can this cause hardware misconfiguration, system lockups, or kernel panics?

Similarly, in proc_bus_pci_read(), the return value of __put_user() is
discarded:

drivers/pci/proc.c:proc_bus_pci_read() {
	...
		unsigned char val;
		pci_user_read_config_byte(dev, pos, &val);
		__put_user(val, buf);
	...
}

Could this lead to silent failures where data is not successfully copied to
userspace despite returning success, leaving the user program to consume
uninitialized memory?

Is it possible to check the return values of __get_user() and __put_user()
in these functions and return -EFAULT if they fail?

> +	inode_unlock(ino);
>  	return nbytes;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730032438.1643450-1-duziming2@huawei.com?part=2

  reply	other threads:[~2026-07-30  3:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-30  3:24 [PATCH v2 0/6] PCI: Fix procfs PCI config access issues Ziming Du
2026-07-30  3:24 ` [PATCH v2 1/6] PCI: Prevent overflow in proc_bus_pci_{read,write}() Ziming Du
2026-07-30  3:16   ` sashiko-bot
2026-07-30  3:24 ` [PATCH v2 2/6] PCI/proc: Serialize config inode size updates Ziming Du
2026-07-30  3:13   ` sashiko-bot [this message]
2026-07-30  3:24 ` [PATCH v2 3/6] PCI/proc: Warn on writes to driver-exclusive config regions Ziming Du
2026-07-30  3:17   ` sashiko-bot
2026-07-30  3:24 ` [PATCH v2 4/6] PCI/sysfs: Avoid runtime PM at config-space EOF Ziming Du
2026-07-30  3:09   ` sashiko-bot
2026-07-30  3:24 ` [PATCH v2 5/6] PCI: Align proc_bus_pci_write() with pci_write_config() Ziming Du
2026-07-30  3:16   ` sashiko-bot
2026-07-30  3:24 ` [PATCH v2 6/6] PCI: Align proc_bus_pci_read() with pci_read_config() Ziming Du
2026-07-30  3:14   ` sashiko-bot

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=20260730031339.AE6D11F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=duziming2@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox