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

[Pei Xiao]

在 2026/6/16 10:46, 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.
Hi Greg,
  I have send two pathes for this bug.  Could you please take a look?
 link:
https://lore.kernel.org/lkml/cover.1782870760.git.xiaopei01@xxxxxxxxxx/

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