Metrics
Affected Vendors & Products
Tue, 01 Apr 2025 16:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
First Time appeared |
Linux
Linux linux Kernel |
|
CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:* |
|
Vendors & Products |
Linux
Linux linux Kernel |
Fri, 28 Mar 2025 16:15:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Weaknesses | CWE-416 | |
Metrics |
cvssV3_1
|
ssvc
|
Fri, 28 Mar 2025 13:45:00 +0000
Type | Values Removed | Values Added |
---|---|---|
References |
| |
Metrics |
threat_severity
|
cvssV3_1
|
Thu, 27 Mar 2025 17:00:00 +0000
Type | Values Removed | Values Added |
---|---|---|
Description | 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). | |
Title | usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait | |
References |
|
|

Status: PUBLISHED
Assigner: Linux
Published: 2025-03-27T16:43:02.950Z
Updated: 2025-05-04T08:44:41.827Z
Reserved: 2025-03-27T16:39:17.988Z
Link: CVE-2022-49755

Updated: 2025-03-28T15:22:33.347Z

Status : Analyzed
Published: 2025-03-27T17:15:40.640
Modified: 2025-04-01T15:40:57.590
Link: CVE-2022-49755
