Katalog CVE

CVE-2026-64594

Niskie ryzyko· EPSS 6%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.16%

Percentyl 6 - wyżej niż 6% wszystkich znanych CVE

Streszczenie

W jądrze Linuxa wykryto podatność w sterowniku USB gadget f_fs (FunctionFS). Niezainicjowana struktura pracy (work_struct) reset_work jest używana podczas odmontowywania systemu plików, co prowadzi do ostrzeżenia WARN_ON i potencjalnego problemu w działaniu. Problem występuje, gdy instancja FunctionFS jest montowana bez opcji "no_disconnect" lub odmontowywana bez wcześniejszej dezaktywacji.

Ocena ryzyka

Podatność może powodować niepożądane ostrzeżenia w logach jądra oraz potencjalne zakłócenia w działaniu systemu podczas odmontowywania funkcji USB. W skrajnych przypadkach może prowadzić do awarii systemu lub problemów ze stabilnością.

Rekomendacja

Zaleca się aktualizację jądra Linux do wersji zawierającej poprawkę, która inicjalizuje reset_work w momencie alokacji struktury ffs_data. Należy również monitorować logi jądra pod kątem ostrzeżeń związanych z workqueue.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS