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

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

[Shuangpeng Bai]

Hi Kernel Maintainers,

I hit the following report while testing current upstream kernel:

KASAN: slab-use-after-free in ipoctal_write_tty

on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)

The reproducer and .config files are here.
https://gist.github.com/shuangpengbai/bc71ccd7ce1454abae45897fdde6813b

I'm happy to test debug patches or provide additional information.

Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>

[  109.226970][ T8370] BUG: KASAN: slab-use-after-free in ipoctal_write_tty (drivers/ipack/devices/ipoctal.c:446 drivers/ipack/devices/ipoctal.c:465)
[  109.227786][ T8370] Read of size 4 at addr ffff88810539e040 by task ipoctal_fd_afte/8370
[  109.228633][ T8370]
[  109.228884][ T8370] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[  109.228887][ T8370] Call Trace:
[  109.228890][ T8370]  <TASK>
[  109.228892][ T8370]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[  109.228898][ T8370]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[  109.228916][ T8370]  kasan_report (mm/kasan/report.c:595)
[  109.228931][ T8370]  ipoctal_write_tty (drivers/ipack/devices/ipoctal.c:446 drivers/ipack/devices/ipoctal.c:465)
[  109.228936][ T8370]  n_tty_write (drivers/tty/n_tty.c:2388)
[  109.228977][ T8370]  file_tty_write (drivers/tty/tty_io.c:1006 drivers/tty/tty_io.c:1081)
[  109.228982][ T8370]  vfs_write (fs/read_write.c:595 fs/read_write.c:688)
[  109.229000][ T8370]  ksys_write (fs/read_write.c:740)
[  109.229006][ T8370]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[  109.229009][ T8370]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[  109.229013][ T8370] RIP: 0033:0x7f4626f1a473
[  109.229017][ T8370] Code: 8b 15 21 2a 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
[  109.229020][ T8370] RSP: 002b:00007ffe7ca57188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  109.229025][ T8370] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f4626f1a473
[  109.229028][ T8370] RDX: 0000000000001000 RSI: 00007ffe7ca571a0 RDI: 0000000000000003
[  109.229031][ T8370] RBP: 0000000000000003 R08: 0000000000000000 R09: 00007f4626fbe0c0
[  109.229033][ T8370] R10: fffffffffffff5fb R11: 0000000000000246 R12: 0000000000000000
[  109.229035][ T8370] R13: 00007ffe7ca571a0 R14: 000000000000000f R15: 00007ffe7ca5719c
[  109.229039][ T8370]  </TASK>
[  109.229041][ T8370]
[  109.253422][ T8370] Freed by task 8370 on cpu 0 at 106.552583s:
[  109.254047][ T8370]  kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[  109.254541][ T8370]  kasan_save_free_info (mm/kasan/generic.c:584)
[  109.255058][ T8370]  __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[  109.255556][ T8370]  kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[  109.255962][ T8370]  device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
[  109.256595][ T8370]  bus_remove_device (drivers/base/bus.c:657)
[  109.257105][ T8370]  device_del (drivers/base/core.c:3895)
[  109.257564][ T8370]  ipack_unregister_bus_member (drivers/ipack/ipack.c:469 drivers/ipack/ipack.c:231)
[  109.258138][ T8370]  bus_for_each_dev (drivers/base/bus.c:383)
[  109.258648][ T8370]  ipack_bus_unregister (drivers/ipack/ipack.c:238)
[  109.259164][ T8370]  tpci200_pci_remove (drivers/ipack/carriers/tpci200.c:611 drivers/ipack/carriers/tpci200.c:628)
[  109.259678][ T8370]  pci_device_remove (drivers/pci/pci-driver.c:512)
[  109.260181][ T8370]  device_release_driver_internal (drivers/base/dd.c:619 drivers/base/dd.c:1352 drivers/base/dd.c:1375)
[  109.260812][ T8370]  unbind_store (drivers/base/bus.c:244)
[  109.261292][ T8370]  kernfs_fop_write_iter (fs/kernfs/file.c:352)
[  109.261840][ T8370]  vfs_write (fs/read_write.c:595 fs/read_write.c:688)
[  109.262286][ T8370]  ksys_write (fs/read_write.c:740)
[  109.262736][ T8370]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[  109.263216][ T8370]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[  109.263835][ T8370]
[  109.264082][ T8370] The buggy address belongs to the object at ffff88810539e000
[  109.264082][ T8370]  which belongs to the cache kmalloc-4k of size 4096
[  109.265511][ T8370] The buggy address is located 64 bytes inside of
[  109.265511][ T8370]  freed 4096-byte region [ffff88810539e000, ffff88810539f000)
[  109.266919][ T8370]


Best,
Shuangpeng

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

[Greg KH]

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?

If virtual, are you sure that the hardware is being emulated properly?

thanks,

greg k-h

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

[Shuangpeng]

> On Jun 15, 2026, at 00:03, Greg KH <gregkh@linuxfoundation.org> 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.

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.

Best,
Shuangpeng

> thanks,
> 
> greg k-h

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

[Greg KH]

On Mon, Jun 15, 2026 at 04:33:09PM -0400, Shuangpeng wrote:
> 
> 
> > On Jun 15, 2026, at 00:03, Greg KH <gregkh@linuxfoundation.org> 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?

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

thanks,

greg k-h

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

[Shuangpeng]

> On Jun 15, 2026, at 16:49, Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> On Mon, Jun 15, 2026 at 04:33:09PM -0400, Shuangpeng wrote:
>> 
>> 
>>> On Jun 15, 2026, at 00:03, Greg KH <gregkh@linuxfoundation.org> 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.

Thanks,
Shuangpeng

> 
> thanks,
> 
> greg k-h

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@linuxfoundation.org> wrote:
> > 
> > On Mon, Jun 15, 2026 at 04:33:09PM -0400, Shuangpeng wrote:
> >> 
> >> 
> >>> On Jun 15, 2026, at 00:03, Greg KH <gregkh@linuxfoundation.org> 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