[BUG] media: usb: siano: WARNING in free_large_kmalloc from smsusb cleanup path

[BUG] media: usb: siano: WARNING in free_large_kmalloc from smsusb cleanup path

[ZW Tang]

Hi,

I am reporting a warning triggered by a syzkaller USB reproducer on
Linux 7.2. The issue is reproducible with HEAD commit
45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229.

The reproducer connects a crafted USB device that is bound to the Siano
SMS USB media driver. During probe, the device repeatedly returns URB
errors. The driver then fails to start the device and enters the cleanup
path.

The relevant failure path is:

smsusb_probe()
smscore_start_device()
smsusb_term_device()
usb_free_urb()
free_large_kmalloc()

The warning is reported by mm/slub.c, but the root cause appears to be in
the Siano USB driver cleanup path. The page owner information shows that
the buffer was allocated through smscore_register_device() and later freed
through smscore_unregister_device(). After that, the cleanup path continues
to release URBs through usb_free_urb(), which reaches free_large_kmalloc()
and triggers the warning.

This looks like a URB/buffer lifetime or ownership mismatch in the smsusb
error path. A partially initialized Siano USB device can fail during probe,
and the cleanup path may free a buffer through an URB after the common
Siano device buffer has already been released or is no longer a valid
kmalloc allocation. The driver should make sure that URB transfer buffers
are not freed twice or freed through the wrong owner during failed probe
cleanup.

Reproducer:

syz reproducer: https://pastebin.com/raw/F41UFB6g
console output: https://pastebin.com/raw/riuUBdGs
kernel config: https://pastebin.com/raw/1ADB4Xp8

Kernel:

HEAD commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
git tree: torvalds/linux
kernel version: 7.2.0-14827-g45c13f3f9e3b #1 PREEMPT(full)

Relevant log:

smsusb:smsusb_onresponse: error, urb status -71, 0 bytes
smsmdtv:smscore_sendrequest_and_wait: sendrequest returned error -22
smsmdtv:smscore_set_device_mode: mode detect failed -22
smsmdtv:smscore_start_device: set device mode failed , rc -22
smsusb:smsusb_init_device: smscore_start_device(...) failed

------------[ cut here ]------------
WARNING: mm/slub.c:6724 at free_large_kmalloc+0x9a/0x110, CPU#1: kworker/1:1/30

CPU: 1 UID: 0 PID: 30 Comm: kworker/1:1 Tainted: G W
7.2.0-14827-g45c13f3f9e3b #1 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
Workqueue: usb_hub_wq hub_event

RIP: 0010+0x9a/0x110

Call Trace:
<TASK>
usb_free_urb+0xd0/0x120
smsusb_term_device+0x1d7/0x3e0
smsusb_probe+0x1aa3/0x2200
usb_probe_interface+0x71e/0xe00
really_probe+0x267/0xb20
__driver_probe_device+0x1f9/0x420
driver_probe_device+0x4f/0x240
__device_attach_driver+0x286/0x430
bus_for_each_drv+0x251/0x2e0
__device_attach+0x2b3/0x440
device_initial_probe+0xa1/0xd0
bus_probe_device+0x12a/0x220
device_add+0x7ec/0xb90
usb_set_configuration+0x19dc/0x2050
usb_generic_driver_probe+0x8d/0x150
usb_probe_device+0x1d3/0x3c0
usb_new_device+0xbc6/0x1ae0
hub_event+0x2c04/0x4ef0
process_scheduled_works+0xc97/0x1920
worker_thread+0xa59/0xfe0
kthread+0x38c/0x480
ret_from_fork+0x508/0xb90
ret_from_fork_asm+0x1a/0x30
</TASK>

page dumped because: Not a kmalloc allocation
page_owner tracks the page as freed

page last allocated via:
___kmalloc_large_node
__kmalloc_noprof
smscore_register_device
smsusb_probe
usb_probe_interface

page last free stack trace:
__free_pages_ok
smscore_unregister_device
smsusb_term_device
smsusb_probe
usb_probe_interface

Re: [BUG] media: usb: siano: WARNING in free_large_kmalloc from smsusb cleanup path

[Greg KH]

On Tue, Sep 01, 2026 at 11:54:43AM +0800, ZW Tang wrote:
> Hi,
> 
> I am reporting a warning triggered by a syzkaller USB reproducer on
> Linux 7.2. The issue is reproducible with HEAD commit
> 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229.
> 
> The reproducer connects a crafted USB device that is bound to the Siano
> SMS USB media driver. During probe, the device repeatedly returns URB
> errors. The driver then fails to start the device and enters the cleanup
> path.

Great, please provide a patch to resolve this and we will be glad to
review it.

thanks,

greg k-h