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

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

thanks,

greg k-h