CVE-2026-64594
CVE CVE-2026-64594EUVD EUVD-2026-53781Veröffentlicht 2026-08-06T07:13:50.000Z
Was das Advisory beschreibt
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.
Quelle: EUVD (ENISA), im Wortlaut der Meldung.
Produkte, die das Advisory nennt
Diese Angaben stammen aus der Meldung selbst, nicht aus einer Prüfung durch uns.
- 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
Die genannten Versionen sind die Angabe der Meldung. Patchlage vergleicht keine Versionsnummern und leitet aus ihnen keine Aussage ab — welche Version installiert ist, muss ein Mensch nachsehen.
Im Produktkatalog geführt
Für diese Produkte kann ein Bestand in Patchlage erfasst werden. Ein Advisory dazu erscheint am Morgen danach im Lagebericht.
- Linux — Linux
Betrifft das einen Ihrer Kundenbestände?
Diese Seite kann die Frage nicht beantworten — sie kennt Ihren Bestand nicht. Wer seine Umgebungen erfasst hat, bekommt die Antwort am Morgen nach der Veröffentlichung, zusammen mit einem Absatz, den er unverändert an den Kunden weitergeben kann.
28 Tage testenPatchlage meldet Treffer und Verdachtsfälle. Zu allem anderen sagt dieses System nichts — weder diese Seite noch der Lagebericht behauptet je, dass ein Bestand sicher ist.