[PATCH AUTOSEL 6.17-5.4] usb: gadget: f_fs: Fix epfile null pointer access after ep enable.

[Sasha Levin <sashal@kernel.org>]

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;
-- 
2.51.0