GHSA-28FC-4VWX-PR32
Vulnerability from github – Published: 2026-08-06 09:30 – Updated: 2026-08-06 09:30In 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.
{
"affected": [],
"aliases": [
"CVE-2026-64594"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T08:16:34Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: initialize reset_work at allocation time\n\nffs_fs_kill_sb() unconditionally calls cancel_work_sync() on\nffs-\u003ereset_work when a functionfs instance is unmounted:\n\n\tffs_data_reset(ffs);\n\tcancel_work_sync(\u0026ffs-\u003ereset_work);\n\nHowever ffs-\u003ereset_work is only ever initialized via INIT_WORK() in\nffs_func_set_alt() and ffs_func_disable(), and only on the\nFFS_DEACTIVATED path. That state is reached solely by ffs_data_closed()\nwhen the instance is mounted with the \"no_disconnect\" option, so for the\ncommon case (no \"no_disconnect\", or mounted and unmounted without ever\nbeing deactivated) reset_work is never initialized.\n\nffs_data_new() allocates the ffs_data with kzalloc_obj() and does not\ninitialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch\nit either, so reset_work.func is left NULL. cancel_work_sync() on such a\nwork then trips the WARN_ON(!work-\u003efunc) guard in __flush_work():\n\n WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount\n Call trace:\n __flush_work\n cancel_work_sync\n ffs_fs_kill_sb [usb_f_fs]\n deactivate_locked_super\n deactivate_super\n cleanup_mnt\n __cleanup_mnt\n task_work_run\n exit_to_user_mode_loop\n el0_svc\n\nOn older kernels cancel_work_sync() on a zero-initialized work struct was\na silent no-op, which hid the missing initialization.\n\nInitialize reset_work once in ffs_data_new() so it is always valid for\nthe lifetime of the ffs_data, and drop the now-redundant INIT_WORK()\ncalls from the two deactivation paths.",
"id": "GHSA-28fc-4vwx-pr32",
"modified": "2026-08-06T09:30:33Z",
"published": "2026-08-06T09:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64594"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0de6ebbabfbbc9c28350283dc97d8a519d5c6dd7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3137b243c93982fe3460335e12f9247739766e10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/69faa3779250df14f51d5084f938a99809546e52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7fe895e0a9651518c4fc082487da770ff9c14c7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ba1867999dbc4085e6d8c52ac5266005b8b2bf07"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c36393b0d14e1e9783888f821ffe29381b8f46dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb19e54ebe9baf3c3243083ade65c937339ccb7b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d5631081be07f20e764d3cb5c98ac0a1004fba51"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.