Re: [BUG] KASAN: slab-use-after-free in ipoctal_write_tty

[Greg KH]

On Mon, Jun 15, 2026 at 08:11:49PM -0400, Shuangpeng wrote:
> 
> 
> > On Jun 15, 2026, at 16:49, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > On Mon, Jun 15, 2026 at 04:33:09PM -0400, Shuangpeng wrote:
> >> 
> >> 
> >>> On Jun 15, 2026, at 00:03, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >>> 
> >>> On Sun, Jun 14, 2026 at 03:48:50PM -0400, Shuangpeng Bai wrote:
> >>>> Hi Kernel Maintainers,
> >>>> 
> >>>> I hit the following report while testing current upstream kernel:
> >>>> 
> >>>> KASAN: slab-use-after-free in ipoctal_write_tty
> >>> 
> >>> Cool, do you have this hardware, or is this only virtual testing?
> >> 
> >> No, I do not have the physical hardware. This was reproduced with 
> >> unmodified QEMU using its existing TPCI200/IP-Octal emulation.
> >> 
> >>> 
> >>> If virtual, are you sure that the hardware is being emulated properly?
> >> 
> >> 
> >> I understand this is not the same as testing on real hardware. However,
> >> my current understanding is that the crash is triggered after a
> >> successful probe through the normal sysfs unbind/remove path while the
> >> ipoctal tty fd is still open. The failing path does not seem to rely on
> >> device-specific emulation details after probe, but rather on the
> >> lifetime of the tty/device state during removal.
> > 
> > What specific sysfs unbind path?  That's only for root and for testing
> > kernel development, it's not a normal thing that a user does at all,
> > right?
> > 
> 
> The sysfs path used by the reproducer is:
> 
> /sys/bus/pci/drivers/tpci200/unbind
> 
> So yes, this is a root-only kernel testing/development path, not a
> normal unprivileged user path.
> 
> >> Please let me know if I am missing anything here. I would also
> >> appreciate any suggestions on what I could check to better evaluate
> >> whether the emulation is appropriate for this report.
> > 
> > What exactly are you trying to test?
> 
> I was trying to test whether the driver handles open ipoctal tty file
> descriptors safely when the backing TPCI200/IPack device is removed.

As you found, it doesn't :)

See the discussions about device unbind and misc/char device nodes on
the mailing lists for many messages about this and potential ways to
resolve it.  As it's not a real issue for drivers like this, it's a very
low priority for other people to resolve, but we will always gladly
review patches from others.

thanks,

greg k-h