In June 2024, Linux kernel maintainers patched a subtle yet critical bug exposed under certain USB gadget usage scenarios, identified as CVE-2024-57913. This issue, although seemingly harmless at first glance, could result in a full kernel panic on systems with panic_on_warn enabled. Below, we break down the bug, the conditions for its exploitation, the underlying code, and how the patch resolved a race that led to devastating system crashes on affected devices.
The Background
The Linux USB gadget subsystem lets devices (like phones or embedded boards) behave as USB peripherals. FunctionFS (functionfs) is a gadget driver that creates endpoints and functions, so user applications (for example, adb on Android) interact with them from userspace using file-like APIs. Two main code paths interact with FunctionFS:
1. User Daemon (adbd) – Handles USB requests (via reading, writing, and opening FunctionFS file descriptors).
2. Kernel (configfs/UDC) – Handles the actual binding of the USB function through the kernel gadget API.
The Problematic Scenario
A race condition arises if the kernel attempts to bind the FunctionFS function (via configfs and the USB gadget core) while user daemons are trying to open or interact with it. If these two actions collide before the gadget is fully active, an internal check in functionfs_bind fires a WARN_ON statement.
With default kernel settings, this merely prints a kernel warning, but with panic_on_warn=1, which is common in production or security-conscious deployments, this warning triggers an immediate kernel panic.
Here's an abbreviated panic trace from an affected kernel
Kernel panic - not syncing: kernel: panic_on_warn set ...
[ 14.542395] Call trace:
[ 14.542464] ffs_func_bind+x1c8/x14a8
[ 14.542468] usb_add_function+xcc/x1f
[ 14.542473] configfs_composite_bind+x468/x588
...
[ 14.542518] usb_gadget_register_driver_owner+x48/xf4
[ 14.542523] gadget_dev_desc_UDC_store+xf8/x144
[ 14.542526] configfs_write_iter+xf/x138
Two Competing Paths
[ ADB Daemon ] [ Kernel/UDC Write ]
usb_ffs_open_thread() UDC write (configfs)
-> open_functionfs() -> configfs_write_iter()
-> adb_open() -> gadget_dev_desc_UDC_store()
-> adb_write() -> usb_gadget_register_driver_owner
-> driver_register()
...
-> gadget_bind_driver()
-> configfs_composite_bind()
-> usb_add_function()
-> ffs_func_bind()
-> functionfs_bind()
(WARN_ON triggers here)
- As daemons open FunctionFS and start read/write operations, a kernel admin or script (via UDC write to configfs) might bind the gadget.
Before patch
int functionfs_bind(...) {
...
if (ffs->state != FFS_ACTIVE) {
WARN_ON(1);
return -EINVAL;
}
...
}
Who can trigger?
- Local attackers with access to configfs and the ability to bind UDC (usb_device_controller) gadgets.
2. Simultaneously trigger a UDC bind through configfs writing.
3. If timing is right (race hit), the binding will encounter a !FFS_ACTIVE state, warning triggers, kernel panics, and system reboots.
The Fix
The fix is simple but crucial—remove the unhelpful WARN_ON, so mistakes in binding can only return a normal error, without bringing down the whole device.
After patch
int functionfs_bind(...) {
...
if (ffs->state != FFS_ACTIVE) {
return -EINVAL;
}
...
}
Full References & Patch Links
- CVE-2024-57913 NVD entry
- Linux Kernel Patch Commit – "usb: gadget: f_fs: Remove WARN_ON in functionfs_bind"
- Linux usb-gadget/functionfs code
- Original Patch Mailing List Discussion
Conclusion
CVE-2024-57913 is a textbook example of how small sanity checks in low-level code—even a defensive WARN_ON—become major denial-of-service vectors when paired with strict kernel configs like panic_on_warn. In embedded or high-availability contexts, this race could bring down entire device fleets. The fix is present from June 2024 kernel releases; make sure to pull it in if you're using Linux gadgets in production.
Stay updated. Review your kernel logs. And remember: a single warning shouldn’t crash your world!
*This post is exclusive research based on direct kernel commit analysis, structured for simplicity and practical guidance. Enjoyed it? Share or reach out for more Linux kernel vulnerability breakdowns.*
Timeline
Published on: 01/19/2025 12:15:25 UTC
Last modified on: 02/27/2025 21:59:09 UTC