Back to CVE records
Not yet scoredPublished Aug 6, 2026

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

Updated under an hour ago ()

Does this affect you?

It affects Linux. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

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

CVSS
Not yet scored
Weakness (CWE)
Not given
Known exploited
Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days)
Not loaded for this CVE
Assigned by
Linux
NVD analysis
Received
Record last updated
Aug 17, 2026
First seen by InfoSec Signals
Oct 9, 2026

Affected products

Affected products
Linux Linux
linux:linux (from the name)
18d6b32fca3841f7cd9479b4024abd8a9b299281 builds before 7fe895e0a9651518c4fc082487da770ff9c14c7f; 18d6b32fca3841f7cd9479b4024abd8a9b299281 builds before 0de6ebbabfbbc9c28350283dc97d8a519d5c6dd7; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before cb19e54ebe9baf3c3243083ade65c937339ccb7b; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before d5631081be07f20e764d3cb5c98ac0a1004fba51; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before c36393b0d14e1e9783888f821ffe29381b8f46dc; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before 69faa3779250df14f51d5084f938a99809546e52; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before ba1867999dbc4085e6d8c52ac5266005b8b2bf07; from 18d6b32fca3841f7cd9479b4024abd8a9b299281 before 3137b243c93982fe3460335e12f9247739766e10
CNA record

References

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.

Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.