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

[Pei Xiao]

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

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.

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.
> 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.

thanks for your responce and time!
Pei.
Thanks!
> thanks,
>
> greg k-h