linux-kernel - Re:Re: [PATCH] USB: add usbfs ioctl to get specific superspeedplus rates

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]

Date:   Wed, 26 Jul 2023 18:10:30 +0800 (CST)
From:   "Dingyan Li" <18500469033@....com>
To:     "Oliver Neukum" <oneukum@...e.com>
Cc:     "Greg KH" <gregkh@...uxfoundation.org>, stern@...land.harvard.edu,
        sebastian.reichel@...labora.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH] USB: add usbfs ioctl to get specific superspeedplus
 rates

At 2023-07-26 17:49:26, "Oliver Neukum" <oneukum@...e.com> wrote:
>
>
>On 26.07.23 11:36, Dingyan Li wrote:
>> At 2023-07-26 16:33:22, "Oliver Neukum" <oneukum@...e.com> wrote:
>>> On 25.07.23 18:11, Dingyan Li wrote:
>>>   
>>>> In proc_conninfo_ex(), the number of returned bytes is determined by
>>>> the smaller number between sizeof(struct usbdevfs_conninfo_ex) and a
>>>> user specified size. So if we only append new members to the end of
>>>> struct usbdevfs_conninfo_ex, it won't impact the bytes in the beginning.
>>>
>>> You have just caused memory corruption in user space by overwriting what
>>> was right behind the buffer of the agreed upon size. Or, not much better,
>>> caused a segmentation fault.
>>>
>>> 	Regards
>>> 		Oliver
>> 
>> How come?
>
>Sorry, I misread the check at the start.
>
>> The actual returned bytes must be smaller than or equal to user specified size.
>> You can check https://elixir.bootlin.com/linux/v6.5-rc3/source/drivers/usb/core/devio.c#L1493
>
>Yes, we can add. But where is the point?
>User space has to be changed to use new sizes.
>

Not necessarily, by this way at least old user space code has a chance to stay
put since it can still get basically the same bytes like before, just not include
the newly appended fields. Of course, if anyone want to access the new fields,
they have to use the new size.

>The problem is not your patch. Add documentation to it and it is fine.
>We have a basic issue here. Do we require libusb to use sysfs or not?
>

Yeah, agree with this.

Regards,
Dingyan