CVE-2026-64594: usb: gadget: f_fs: initialize reset_work at allocation time

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:

ffsdatareset(ffs); cancelworksync(&ffs->resetwork);

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) resetwork 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 WARNON(!work->func) guard in flushwork():

WARNING: kernel/workqueue.c:4301 at flushwork+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 INITWORK() calls from the two deactivation paths.