Description
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.
Published: 2026-08-06
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel contains an improper initialization flaw in usb gadget functionfs where the reset_work structure is not initialized until specific deactivation paths; cancel_work_sync called during unmount on this uninitialized work triggers a kernel warning that may have led to kernel panic or silent failure on older kernels, giving an attacker the ability to destabilize the system if they can trigger the unmount event.

Affected Systems

This defect is present in all Linux kernel versions that have not incorporated the patch committing the initialization of reset_work in ffs_data_new(); affected systems include any device running a kernel older than the commit that introduced the fix.

Risk and Exploitability

Without the patch the vulnerability is exploitable only by an entity with the ability to execute privileged actions such as mounting and unmounting functionfs; the risk is that a kernel crash or system instability could occur, resulting in a denial‑of‑service condition. The CVSS score is not disclosed, the EPSS score is not available, and the vulnerability is not listed in the CISA KEV catalog, suggesting a lower but non‑negligible risk for environments where USB gadget functionality is used.

Generated by OpenCVE AI on August 6, 2026 at 08:22 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the system to a Linux kernel version that includes the patch which initializes reset_work in ffs_data_new()
  • If an immediate kernel upgrade is not possible, avoid mounting functionfs with the "no_disconnect" option and refrain from unmounting functionfs instances that may trigger reset_work cleanup
  • Consider disabling USB gadget functionality entirely if not required for the device operation

Generated by OpenCVE AI on August 6, 2026 at 08:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 06 Aug 2026 08:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-476

Thu, 06 Aug 2026 07:30:00 +0000

Type Values Removed Values Added
Description 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.
Title usb: gadget: f_fs: initialize reset_work at allocation time
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-06T07:13:50.309Z

Reserved: 2026-07-19T15:36:31.799Z

Link: CVE-2026-64594

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-06T11:00:06Z

Weaknesses