Re: [PATCH 0/2] ipack: ipoctal: fix races and UAFs during module removal

[Pei Xiao]

在 2026/7/1 18:37, Greg KH 写道:
> On Wed, Jul 01, 2026 at 02:16:50PM +0800, Pei Xiao wrote:
>>
>> 在 2026/7/1 13:41, Greg KH 写道:
>>> On Wed, Jul 01, 2026 at 10:01:08AM +0800, Pei Xiao wrote:
>>>> When the ipoctal device is removed while a userspace process still
>>>> holds a tty fd open, several races and use-after-free bugs can be
>>>> triggered.  This series addresses the following issues:
>>> Cool, but why remove the module at all?
>> 1. Carrier hot-unplug: the IPack carrier (e.g., TPCI-200) is a PCI
>>    device.  When the carrier is physically removed or the PCI device
>>    is unbound via sysfs, ipack_bus_unregister() calls
>>    ipack_device_del() on every mezzanine device, which invokes
>>    ipoctal_remove().  This happens regardless of whether userspace
>>    still holds a tty fd open -- the carrier is gone, so the devices
>>    must go too.  The ipack_get_carrier()/try_module_get() in
>>    ipoctal_install() only prevents rmmod of the carrier module, not
>>    physical removal.
> Yes, but does anyone actually remove the module or unbind it or remove
> it physically in a real system?
>
> This is very very old hardware, removing it while active is not
> something that the hardware is designed to support, so why do we need to
> support it in the kernel?
>
> Do you have this hardware?
>
>> 2. Syzkaller/syzbot-style fuzzing: the original report from
>>    Shuangpeng Bai  exercises exactly these paths.  Even without
>>    real hardware, syzkaller can trigger the races by binding and
>>    unbinding drivers.
> Sure, but remember bind/unbind is a DEBUG TOOL!  And it is controlled by
> root, so it is a "best effort" thing that is there for kernel developers
> to use for working on their code.  No real customer runs that code path
> (and if they do, they are an admin and can do much worse things to the
> system if they wanted to.)
>
>> So while rmmod of ipoctal itself is blocked by the tty layer (via
>> drv->owner), the remove callback can and will be called through
>> carrier removal or driver unbind.  The crashes are real.
> But not a real use case ;)
>
>>> And do you have this hardware to test with?
>> I don't have the hardware.  However:
>>
>> - The fixes are structural and follow well-established kernel
>>   patterns: kref for lifetime management, rwsem for TOCTOU races,
>>   and caching a module pointer to avoid chasing a freed bus pointer.
>>   These are the same idioms used across the tty layer and other
>>   subsystems.
>>
>> The original reporter (Shuangpeng, CC'd) has tested this crash passed.
> With real hardware?
>
> Ideally we could just remove the driver as I doubt anyone uses it
> anymore.  You can't even buy the device.
You are right, but I saw the phrase 'gladly review patches from others' and
 thought that although this is a very, very old driver, there might
still be a 
chance to get my changes merged. Haha, I really owe an apology to 
Shuangpeng, who tested my patches several times for me.

 Also, I may have wasted your time, given how busy you are.

Pei.
Thanks!
>
> thanks,
>
> greg k-h