Re: [REGRESSION] media: em28xx: list_del corruption on dual-TS disconnect

[Thorsten Leemhuis]

On 11/6/26 05:59, Shantanu Sarkar wrote:

> Commit 826915b6b65e ("media: em28xx: fix use-after-free of
> dev_next->devlist on disconnect"), merged for v7.3 and backported to
> stable, makes em28xx_close_extension() unconditionally do
> 
> if (dev->dev_next)
> list_del(&dev->dev_next->devlist);

>From a very quick look this seems to be the problem that was reported
earlier; a fix is discussed here:

[PATCH] media: em28xx: fix NULL pointer dereference on disconnect of
dual-TS devices
https://lore.kernel.org/all/20261104052800.44551-1-sikorski.grzegorz@xxxxxxxxx/

If it's a different problem, please speak up.

Ciao, Thorsten

> On a dual-TS board whose secondary device is not audio-only (the
> normal DVB case), dev_next->devlist was never added to em28xx_devlist.
> em28xx_duplicate_dev() kmemdup()s the zero-allocated primary in
> em28xx_usb_probe() before request_modules() links the primary, so
> dev_next->devlist is {NULL, NULL}, and the list_del() on disconnect
> crashes. On current mainline (7.4.0-rc1, 05441d697f7f), with
> CONFIG_DEBUG_LIST=y:
> 
>   em28xx 5-1:0.244: Closing input extension
>   list_del corruption, ffff88810de88250->next is NULL
>   ------------[ cut here ]------------
>   kernel BUG at lib/list_debug.c:53!
>   Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
>   CPU: 1 UID: 0 PID: 32 Comm: kworker/1:1 Not tainted 7.4.0-rc1 #1 PREEMPT(full)
>   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
>   Workqueue: usb_hub_wq hub_event
>   Call Trace:
>    em28xx_close_extension+0x15a/0x390
>    em28xx_usb_disconnect+0x16b/0x2f0
>    usb_unbind_interface+0x295/0x9c0
>    device_release_driver_internal+0x48d/0x7d0
>    bus_remove_device+0x444/0x560
>    device_del+0x523/0x8f0
>    usb_disable_device+0x3d4/0x8d0
>    usb_disconnect+0x346/0x9a0
>    hub_event+0x1bd6/0x4d10
> 
> Reproducer: syzbot's C reproducer for the bug the commit fixes
> (https://syzkaller.appspot.com/bug?extid=99d6c66dbbc484f50e1c), with
> one byte changed so the emulated 2040:026d device (WinTV-dualHD
> 01595) exposes a DVB isoc endpoint 0x84 instead of the audio endpoint
> 0x83, i.e. in the memcpy of the extra endpoint descriptor:
> 
> -"\x83\x99\x35\x19\x1f"
> +"\x84\x99\x35\x19\x1f"
> 
> Results in QEMU (x86_64, syzbot's upstream config, 5 min per boot):
>   - tree at 826915b6b65e^ (before the commit):  no crash (3 of 3 boots)
>   - same tree with 826915b6b65e applied:         crash above (3 of 3)
>   - mainline 05441d697f7f (7.4.0-rc1):           crash above (2 of 2)
> The unmodified syzbot reproducer (audio-only secondary) is fixed by
> the commit, as intended. I have not tested real hardware or the stable
> backports (6.12.y, 6.18.y, 7.2.y, 7.3.y carry the same change).
> 
> How this was found: we were testing AI coding agents on old syzbot
> bugs, and an AI-assisted review of the candidate patches flagged this
> path; I then confirmed it with the reproducer above. No AI-written
> patch is included.
> 
> #regzbot introduced: 826915b6b65e
> 
> Thanks,
> Shantanu