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] [day] [month] [year] [list]

Message-ID: <590a8869-6166-4b5d-8b3e-5a144062699a@huawei.com>
Date: Sun, 4 Jan 2026 15:17:52 +0800
From: duziming <duziming2@...wei.com>
To: Bjorn Helgaas <helgaas@...nel.org>, Ilpo Järvinen
	<ilpo.jarvinen@...ux.intel.com>
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()


在 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@...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)
> 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.

>