CVE-2026-64594

CVE CVE-2026-64594EUVD EUVD-2026-53781Published 2026-08-06T07:13:50.000Z

What the advisory describes

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.

Source: EUVD (ENISA), in the words of the advisory.

Products the advisory names

These come from the advisory itself, not from any check we performed.

• Linux — Linux 18d6b32fca3841f7cd9479b4024abd8a9b299281 <69faa3779250df14f51d5084f938a99809546e52; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <0de6ebbabfbbc9c28350283dc97d8a519d5c6dd7; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <ba1867999dbc4085e6d8c52ac5266005b8b2bf07; patch: 0; patch: 6.12.97; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <c36393b0d14e1e9783888f821ffe29381b8f46dc; patch: 5.15.212; patch: 7.2-rc3; 4.0; patch: 6.1.178; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <cb19e54ebe9baf3c3243083ade65c937339ccb7b; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <3137b243c93982fe3460335e12f9247739766e10; patch: 5.10.261; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <d5631081be07f20e764d3cb5c98ac0a1004fba51; patch: 6.18.40; 18d6b32fca3841f7cd9479b4024abd8a9b299281 <7fe895e0a9651518c4fc082487da770ff9c14c7f; patch: 6.6.145; patch: 7.1.4

The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.

Carried in the product catalogue

An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.

• Linux — Linux

Patchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.