Re: [PATCH v2 2/3] PCI: Prevent overflow in proc_bus_pci_write()

[duziming]

在 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@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > Signed-off-by: Ziming Du <duziming2@xxxxxxxxxx>
> > ---
> >   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@xxxxxxxxxxxxxxx/

However, it does not result in an overflow to a negative number.

> 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;
> > --
> > 2.43.0