CVE-2026-64594

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ffs: initialize resetwork at allocation time

ffsfskillsb() unconditionally calls cancelworksync() on ffs->resetwork when a functionfs instance is unmounted:

ffs_data_reset(ffs);
cancel_work_sync(&ffs->reset_work);

However ffs->resetwork is only ever initialized via INITWORK() in ffsfuncsetalt() and ffsfuncdisable(), and only on the FFSDEACTIVATED path. That state is reached solely by ffsdataclosed() when the instance is mounted with the "nodisconnect" option, so for the common case (no "nodisconnect", or mounted and unmounted without ever being deactivated) reset_work is never initialized.

ffsdatanew() allocates the ffsdata with kzallocobj() and does not initialize resetwork, and ffsdatareset()/ffsdataclear() do not touch it either, so resetwork.func is left NULL. cancelworksync() on such a work then trips the WARN_ON(!work->func) guard in _flushwork():

WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount Call trace: __flushwork cancelworksync ffsfskillsb [usbffs] deactivatelockedsuper deactivatesuper cleanupmnt __cleanupmnt taskworkrun exittousermodeloop el0svc

On older kernels cancelworksync() on a zero-initialized work struct was a silent no-op, which hid the missing initialization.

Initialize resetwork once in ffsdatanew() so it is always valid for the lifetime of the ffsdata, and drop the now-redundant INIT_WORK() calls from the two deactivation paths.