CVE-2026-64594

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: initialize reset_work at allocation time<br /> <br /> ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on<br /> ffs-&gt;reset_work when a functionfs instance is unmounted:<br /> <br /> ffs_data_reset(ffs);<br /> cancel_work_sync(&amp;ffs-&gt;reset_work);<br /> <br /> However ffs-&gt;reset_work is only ever initialized via INIT_WORK() in<br /> ffs_func_set_alt() and ffs_func_disable(), and only on the<br /> FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed()<br /> when the instance is mounted with the "no_disconnect" option, so for the<br /> common case (no "no_disconnect", or mounted and unmounted without ever<br /> being deactivated) reset_work is never initialized.<br /> <br /> ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not<br /> initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch<br /> it either, so reset_work.func is left NULL. cancel_work_sync() on such a<br /> work then trips the WARN_ON(!work-&gt;func) guard in __flush_work():<br /> <br /> WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount<br /> Call trace:<br /> __flush_work<br /> cancel_work_sync<br /> ffs_fs_kill_sb [usb_f_fs]<br /> deactivate_locked_super<br /> deactivate_super<br /> cleanup_mnt<br /> __cleanup_mnt<br /> task_work_run<br /> exit_to_user_mode_loop<br /> el0_svc<br /> <br /> On older kernels cancel_work_sync() on a zero-initialized work struct was<br /> a silent no-op, which hid the missing initialization.<br /> <br /> Initialize reset_work once in ffs_data_new() so it is always valid for<br /> the lifetime of the ffs_data, and drop the now-redundant INIT_WORK()<br /> calls from the two deactivation paths.