From: Owen Gu guhuinan@xiaomi.com
[ Upstream commit cfd6f1a7b42f62523c96d9703ef32b0dbc495ba4 ]
A race condition occurs when ffs_func_eps_enable() runs concurrently with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset() sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading to a NULL pointer dereference when accessing epfile->ep in ffs_func_eps_enable() after successful usb_ep_enable().
The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and ffs_data_close() functions, and its modification is protected by the spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function is also protected by ffs->eps_lock.
Thus, add NULL pointer handling for ffs->epfiles in the ffs_func_eps_enable() function to fix issues
Signed-off-by: Owen Gu guhuinan@xiaomi.com Link: https://lore.kernel.org/r/20250915092907.17802-1-guhuinan@xiaomi.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES Prevents a real NULL-dereference crash in FunctionFS caused by a race between endpoint reset and re-enable.
- Root cause: `ffs_data_clear()` drops `ffs->epfiles` under `eps_lock` while leaving `ffs->eps_count` untouched until later in `ffs_data_reset()` (`drivers/usb/gadget/function/f_fs.c:2209-2259`). If `ffs_func_eps_enable()` runs in that window, it sees a stale non- zero `count` but `epfile == NULL`, leading to `epfile->ep` dereference and a kernel oops after `usb_ep_enable()` succeeds (`drivers/usb/gadget/function/f_fs.c:2415-2429`). - Fix: the commit adds an early null-check on `ffs->epfiles` and aborts with `-ENOMEM` before touching the per-endpoint bookkeeping (`drivers/usb/gadget/function/f_fs.c:2410-2413,2438-2440`), which keeps the crash from happening while still unwinding cleanly through the existing error paths (`ffs_func_set_alt()` simply propagates the failure, `drivers/usb/gadget/function/f_fs.c:3730-3759`). - Impact if unfixed: FunctionFS functions can hit this race during disconnects/resets, taking the whole gadget stack down with a NULL- pointer exception—serious for production devices relying on FunctionFS (we confirmed the same vulnerable logic is present in v6.6). - Risk assessment: the guard executes only when the race actually occurs; normal enable sequences (where `ffs->epfiles` is valid) are untouched. Returning `-ENOMEM` matches existing allocation-failure handling in this code, and skipping `wake_up_interruptible()` in the no-epfile case is safe because there are no endpoint waiters left once the epfile array is gone. - Backport fit: single-file change, no new APIs, no dependencies on later infrastructure, and it directly fixes a crash-worthy regression—all lining up with stable tree criteria.
Natural next step: run the gadget/functionfs tests (or a simple mount/enable cycle) on the target stable branch after applying the patch to verify there’s no unexpected alt-setting fallout.
drivers/usb/gadget/function/f_fs.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c index 08a251df20c43..04058261cdd03 100644 --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -2407,7 +2407,12 @@ static int ffs_func_eps_enable(struct ffs_function *func) ep = func->eps; epfile = ffs->epfiles; count = ffs->eps_count; - while(count--) { + if (!epfile) { + ret = -ENOMEM; + goto done; + } + + while (count--) { ep->ep->driver_data = ep;
ret = config_ep_by_speed(func->gadget, &func->function, ep->ep); @@ -2431,6 +2436,7 @@ static int ffs_func_eps_enable(struct ffs_function *func) }
wake_up_interruptible(&ffs->wait); +done: spin_unlock_irqrestore(&func->ffs->eps_lock, flags);
return ret;