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

[Pei Xiao]

在 2026/6/17 00:26, Shuangpeng 写道:
>
>> On Jun 15, 2026, at 22:46, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>
>> 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 for the explanation and the pointers.
>
> I will read through the related discussions to better understand how opened
> file descriptors are expected to be handled when the underlying device or
> driver is removed. This is very helpful.
>
> Thanks,
> Shuangpeng
Hi Shuangppeng,
Are you working on this bug? If not, could you help test this patch?
If you're already handling this, I apologize for the interruption.

Thanks!

>> thanks,
>>
>> greg k-h
>
>