From: Yongqiang Liu <liuyongqiang13@huawei.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:
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@huawei.com>
Signed-off-by: Ziming Du <duziming2@huawei.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;
if (nbytes >= size)
nbytes = size;
--
2.43.0[+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@huawei.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
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.
If this is easily reproducible with "dd" or similar, could maybe
include a sample command line?
> 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@huawei.com>
> Signed-off-by: Ziming Du <duziming2@huawei.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?
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?
> if (nbytes >= size)
> nbytes = size;
> --
> 2.43.0
>
在 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@huawei.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@huawei.com>
>> Signed-off-by: Ziming Du <duziming2@huawei.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.
>
> 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
>>
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@huawei.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@huawei.com>
> > > Signed-off-by: Ziming Du <duziming2@huawei.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;
On Wed, Dec 31, 2025 at 11:31:47AM +0200, Ilpo Järvinen wrote:
> 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@huawei.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@huawei.com>
> > > > Signed-off-by: Ziming Du <duziming2@huawei.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)
Isn't *ppos a signed quantity? If so, wouldn't we want to check for
"*ppos < 0"?
在 2026/1/1 1:04, Bjorn Helgaas 写道:
> On Wed, Dec 31, 2025 at 11:31:47AM +0200, Ilpo Järvinen wrote:
>> 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@huawei.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@huawei.com>
>>>>> Signed-off-by: Ziming Du <duziming2@huawei.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)
> Isn't *ppos a signed quantity? If so, wouldn't we want to check for
> "*ppos < 0"?
If *ppos < 0, it will be discarded in the previous process, just like in
do_pwritev(), where it returns -EINVAL
when pos is negative. So we think that here using "*ppos > INT_MAX"
might be more reasonable.
>
© 2016 - 2026 Red Hat, Inc.