linux-kernel - Re: [PATCH v2 2/3] PCI: Prevent overflow in proc_bus_pci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5cc94da-23e7-0185-0b5a-b35125234af4@linux.intel.com>
Date: Wed, 31 Dec 2025 11:31:47 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: duziming <duziming2@...wei.com>, Bjorn Helgaas <helgaas@...nel.org>
cc: bhelgaas@...gle.com, jbarnes@...tuousgeek.org, chrisw@...hat.com, 
    alex.williamson@...hat.com, linux-pci@...r.kernel.org, 
    LKML <linux-kernel@...r.kernel.org>, liuyongqiang13@...wei.com, 
    Krzysztof Wilczyński <kwilczynski@...nel.org>
Subject: Re: [PATCH v2 2/3] PCI: Prevent overflow in proc_bus_pci_write()

On Tue, 30 Dec 2025, duziming wrote:
> 在 2025/12/30 2:07, Bjorn Helgaas 写道:
> > [+cc Krzysztof; I thought we looked at this long ago?]
> > 
> > On Wed, Dec 24, 2025 at 05:27:18PM +0800, Ziming Du wrote:
> > > From: Yongqiang Liu <liuyongqiang13@...wei.com>
> > > 
> > > When the value of ppos over the INT_MAX, the pos is over set to a negtive
> > > value which will be passed to get_user() or pci_user_write_config_dword().
> > > Unexpected behavior such as a softlock will happen as follows:
> > s/negtive/negative/
> > s/softlock/soft lockup/ to match message below
> Thanks for pointing out the ambiguous parts.
> > s/ppos/pos/ (or fix this to refer to "*ppos", which I think is what
> > you're referring to)
> > 
> > I guess the point is that proc_bus_pci_write() takes a "loff_t *ppos",
> > loff_t is a signed type, and negative read/write offsets are invalid.
> 
> Actually, the *loff_t *ppos *passed in is not a negative value. The root cause
> of the issue
> 
> lies in the cast *int* *pos = *ppos*. When the value of **ppos* over the
> INT_MAX, the pos is over set
> 
> to a negative value. This negative *pos* then propagates through subsequent
> logic, leading to the observed errors.
> 
> > If this is easily reproducible with "dd" or similar, could maybe
> > include a sample command line?
> 
> We reproduced the issue using the following POC:
> 
>     #include <stdio.h>
> 
>     #include <string.h>
>     #include <unistd.h>
>     #include <fcntl.h>
>     #include <sys/uio.h>
> 
>     int main() {
>     int fd = open("/proc/bus/pci/00/02.0", O_RDWR);
>     if (fd < 0) {
>         perror("open failed");
>         return 1;
>     }
>     char data[] = "926b7719201054f37a1d9d391e862c";
>     off_t offset = 0x80800001;
>     struct iovec iov = {
>         .iov_base = data,
>         .iov_len = 0xf
>     };
>     pwritev(fd, &iov, 1, offset);
>     return 0;
> }
> 
> > >   watchdog: BUG: soft lockup - CPU#0 stuck for 130s! [syz.3.109:3444]
> > >   RIP: 0010:_raw_spin_unlock_irq+0x17/0x30
> > >   Call Trace:
> > >    <TASK>
> > >    pci_user_write_config_dword+0x126/0x1f0
> > >    proc_bus_pci_write+0x273/0x470
> > >    proc_reg_write+0x1b6/0x280
> > >    do_iter_write+0x48e/0x790
> > >    vfs_writev+0x125/0x4a0
> > >    __x64_sys_pwritev+0x1e2/0x2a0
> > >    do_syscall_64+0x59/0x110
> > >    entry_SYSCALL_64_after_hwframe+0x78/0xe2
> > > 
> > > Fix this by add check for the pos.
> > > 
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Signed-off-by: Yongqiang Liu <liuyongqiang13@...wei.com>
> > > Signed-off-by: Ziming Du <duziming2@...wei.com>
> > > ---
> > >   drivers/pci/proc.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
> > > index 9348a0fb8084..200d42feafd8 100644
> > > --- a/drivers/pci/proc.c
> > > +++ b/drivers/pci/proc.c
> > > @@ -121,7 +121,7 @@ static ssize_t proc_bus_pci_write(struct file *file,
> > > const char __user *buf,
> > >   	if (ret)
> > >   		return ret;
> > >   -	if (pos >= size)
> > > +	if (pos >= size || pos < 0)
> > >   		return 0;
> > I see a few similar cases that look like this; maybe we should do the
> > same?
> > 
> >    if (pos < 0)
> >      return -EINVAL;
> > 
> > Looks like proc_bus_pci_read() has the same issue?
> 
> proc_bus_pci_read() may also trigger similar issue as mentioned by Ilpo
> Järvinen in
> 
> https://lore.kernel.org/linux-pci/e5a91378-4a41-32fb-00c6-2810084581bd@linux.intel.com/
> 
> However, it does not result in an overflow to a negative number.

Why does the cast has to happen first here?

This would ensure _correctness_ without any false alignment issues for 
large numbers:

	int pos;
	int size = dev->cfg_size;

	...
	if (*ppos > INT_MAX)
		return -EINVAL;
	pos = *ppos;

(I'm not sure though if this should return 0 or -EINVAL when *ppos >= 
size as it currently returns 0 for non-overflowing values when pos >= 
size.)

-- 
 i.


> > What about pci_read_config(), pci_write_config(),
> > pci_llseek_resource(), pci_read_legacy_io(), pci_write_legacy_io(),
> > pci_read_resource_io(), pci_write_resource_io(), pci_read_rom()?
> > These are all sysfs things; does the sysfs infrastructure take care of
> > negative offsets before we get to these?
> 
> In do_pwritev(), the following check has been performed:
> 
>    if (pos < 0)
>          return -EINVAL;
> 
> Theoretically, a negative offset should not occur.
> 
> > >   	if (nbytes >= size)
> > >   		nbytes = size;