CVE-2022-49755 in Linux
Summary
by MITRE • 03/27/2025
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait
While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind.
Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free.
Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 12/06/2025
The vulnerability CVE-2022-49755 resides within the Linux kernel's USB gadget framework, specifically in the function filesystem (f_fs) implementation that handles USB gadget functionality. This issue manifests during rapid composition switching operations where the kernel's USB gadget subsystem experiences a race condition that can lead to critical memory corruption. The flaw occurs in the interaction between the endpoint zero (ep0) write and read operations with the function filesystem unbind process, creating a scenario where memory safety is compromised through improper synchronization mechanisms. The vulnerability is particularly concerning as it affects the core USB gadget functionality that enables Linux systems to act as USB devices, potentially impacting a wide range of embedded systems and device drivers.
The technical root cause of this vulnerability stems from insufficient synchronization between concurrent operations within the function filesystem implementation. During fast composition switches, the ffs_ep0_write function invokes ffs_ep0_queue_wait while holding the lock &ffs->ev.waitq.lock, but the functionfs_unbind operation operates independently without proper coordination. This lack of synchronization allows the unbind process to free the ep0req structure while ffs_ep0_queue_wait is still attempting to access it, resulting in a classic use-after-free condition. The absence of null pointer checks in the ffs_ep0_queue_wait function exacerbates the issue, as the code assumes ep0req will remain valid during execution. This race condition falls under the CWE-362 category of "Concurrent Execution using Shared Resource with Improper Synchronization" and represents a violation of proper inter-process communication protocols.
The operational impact of CVE-2022-49755 extends beyond simple memory corruption, potentially enabling privilege escalation and system instability in environments where USB gadget functionality is utilized. Attackers could exploit this vulnerability to execute arbitrary code with kernel privileges, particularly in embedded systems or devices that rely heavily on USB gadget drivers for device functionality. The vulnerability affects systems running Linux kernels that implement the function filesystem USB gadget framework, which is commonly found in networking equipment, storage devices, and embedded systems. The race condition scenario can be triggered through specific sequences of USB device configuration changes, making it potentially exploitable in environments where dynamic USB device configuration occurs frequently. This vulnerability aligns with ATT&CK technique T1068 which involves local privilege escalation through kernel vulnerabilities.
Mitigation strategies for CVE-2022-49755 involve implementing proper serialization between the ffs_ep0_queue_wait function and the functionfs_unbind operation through mutex locking mechanisms as specified in the patch. The fix requires introducing a mutex_lock(ffs->mutex) to ensure that these two operations cannot execute concurrently, thereby preventing the race condition that leads to the use-after-free scenario. System administrators should prioritize applying the kernel patches that address this vulnerability, particularly in production environments where USB gadget functionality is actively used. Additionally, monitoring for unusual USB device configuration patterns and implementing proper kernel update policies can help reduce exposure. Organizations utilizing embedded systems or device drivers that depend on function filesystem USB gadget implementations should conduct thorough testing of updated kernel versions to ensure compatibility while maintaining security posture. The vulnerability demonstrates the critical importance of proper synchronization in kernel-level code and highlights the need for comprehensive testing of concurrent operations in complex subsystems.