[PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Jiasheng Jiang]

The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
managed and tied to userspace configuration via ConfigFS. It can be
NULL if the USB host sends requests before the nexus is fully
established or immediately after it is dropped.

Currently, functions like `bot_submit_command()` and the data
transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
dereference `tv_nexus->tvn_se_sess` without any validation. If a
malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
command during this race window, it triggers a NULL pointer
dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer
functions like `usbg_submit_command()` and `bot_send_bad_response()`
correctly implement a NULL check for `tv_nexus` before proceeding.

Fix this by bringing consistency to the nexus handling. Add the
missing `if (!tv_nexus)` checks to the vulnerable BOT command and
request processing paths, aborting the command gracefully with an
error instead of crashing the system.

Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
---
 drivers/usb/gadget/function/f_tcm.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
index 6e8804f04baa..9554ddd9b4b8 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1222,6 +1222,11 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
@@ -1482,6 +1487,11 @@ static void bot_cmd_work(struct work_struct *work)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
-- 
2.25.1

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Thinh Nguyen]

On Mon, Feb 16, 2026, Jiasheng Jiang wrote:
> The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
> managed and tied to userspace configuration via ConfigFS. It can be
> NULL if the USB host sends requests before the nexus is fully
> established or immediately after it is dropped.
> 
> Currently, functions like `bot_submit_command()` and the data
> transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
> dereference `tv_nexus->tvn_se_sess` without any validation. If a
> malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
> command during this race window, it triggers a NULL pointer
> dereference, leading to a kernel panic (local DoS).
> 
> This exposes an inconsistent API usage within the module, as peer
> functions like `usbg_submit_command()` and `bot_send_bad_response()`
> correctly implement a NULL check for `tv_nexus` before proceeding.
> 
> Fix this by bringing consistency to the nexus handling. Add the
> missing `if (!tv_nexus)` checks to the vulnerable BOT command and
> request processing paths, aborting the command gracefully with an
> error instead of crashing the system.
> 
> Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> ---
>  drivers/usb/gadget/function/f_tcm.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
> index 6e8804f04baa..9554ddd9b4b8 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1222,6 +1222,11 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
>  	se_cmd = &cmd->se_cmd;
>  	tpg = cmd->fu->tpg;
>  	tv_nexus = tpg->tpg_nexus;
> +	if (!tv_nexus) {
> +		pr_err("Missing nexus, ignoring command\n");
> +		return;
> +	}
> +
>  	dir = get_cmd_dir(cmd->cmd_buf);
>  	if (dir < 0)
>  		goto out;
> @@ -1482,6 +1487,11 @@ static void bot_cmd_work(struct work_struct *work)
>  	se_cmd = &cmd->se_cmd;
>  	tpg = cmd->fu->tpg;
>  	tv_nexus = tpg->tpg_nexus;
> +	if (!tv_nexus) {
> +		pr_err("Missing nexus, ignoring command\n");
> +		return;
> +	}
> +
>  	dir = get_cmd_dir(cmd->cmd_buf);
>  	if (dir < 0)
>  		goto out;
> -- 
> 2.25.1
> 
> 

While the patch itself is fine, we should prevent this situation from
occurring in the first place. That is, we should enforce the config
dependency and prevent the users from removing the nexus if the gadget
driver is bound. Likewise, we should prevent the gadget driver from
binding if no nexus is established.

BR,
Thinh

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Sebastian Andrzej Siewior]

On 2026-02-18 05:22:21 [+0000], Thinh Nguyen wrote:
> > Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
> > Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
…
> While the patch itself is fine, we should prevent this situation from
> occurring in the first place. That is, we should enforce the config
> dependency and prevent the users from removing the nexus if the gadget
> driver is bound. Likewise, we should prevent the gadget driver from
> binding if no nexus is established.

Is this an actual problem or just something that looks like it could
happen? My memory is that the tcm holds a reference on it and the
referenced commit just split/moved  the code. So if it is a problem then
it should have been there longer than that.

> BR,
> Thinh

Sebastian

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Thinh Nguyen]

On Wed, Feb 18, 2026, Sebastian Andrzej Siewior wrote:
> On 2026-02-18 05:22:21 [+0000], Thinh Nguyen wrote:
> > > Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
> > > Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> …
> > While the patch itself is fine, we should prevent this situation from
> > occurring in the first place. That is, we should enforce the config
> > dependency and prevent the users from removing the nexus if the gadget
> > driver is bound. Likewise, we should prevent the gadget driver from
> > binding if no nexus is established.
> 
> Is this an actual problem or just something that looks like it could
> happen? My memory is that the tcm holds a reference on it and the
> referenced commit just split/moved  the code. So if it is a problem then
> it should have been there longer than that.
> 

Looks like we only hold the reference to the session cmds, and we track
the tpg_port_count if there's an established link. But we don't guard or
deactivate the f_tcm usb function when we unregister the tcm and remove
the nexus. As far as the host can tell, the device is still connected
and the function is still active.

This exists since the beginning. The Fixes tag should have pointed to
c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")

We can guard against unlinking the port while the gadget_driver is bound
or we can just deactivate the usb function when that happens. The latter
is probably a better option.

BR,
Thinh

[PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Jiasheng Jiang]

The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
managed and tied to userspace configuration via ConfigFS. It can be
NULL if the USB host sends requests before the nexus is fully
established or immediately after it is dropped.

Currently, functions like `bot_submit_command()` and the data
transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
dereference `tv_nexus->tvn_se_sess` without any validation. If a
malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
command during this race window, it triggers a NULL pointer
dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer
functions like `usbg_submit_command()` and `bot_send_bad_response()`
correctly implement a NULL check for `tv_nexus` before proceeding.

Fix this by bringing consistency to the nexus handling. Add the
missing `if (!tv_nexus)` checks to the vulnerable BOT command and
request processing paths, aborting the command gracefully with an
error instead of crashing the system.

Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
---
 drivers/usb/gadget/function/f_tcm.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
index 6e8804f04baa..9554ddd9b4b8 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1222,6 +1222,11 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
@@ -1482,6 +1487,11 @@ static void bot_cmd_work(struct work_struct *work)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
-- 
2.25.1

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Jiasheng Jiang]

On Thu, 19 Feb 2026 01:30:16 +0000, Thinh Nguyen wrote:
> On Wed, Feb 18, 2026, Sebastian Andrzej Siewior wrote:
>> On 2026-02-18 05:22:21 [+0000], Thinh Nguyen wrote:
>> > > Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
>> > > Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
>> …
>> > While the patch itself is fine, we should prevent this situation from
>> > occurring in the first place. That is, we should enforce the config
>> > dependency and prevent the users from removing the nexus if the gadget
>> > driver is bound. Likewise, we should prevent the gadget driver from
>> > binding if no nexus is established.
>> 
>> Is this an actual problem or just something that looks like it could
>> happen? My memory is that the tcm holds a reference on it and the
>> referenced commit just split/moved  the code. So if it is a problem then
>> it should have been there longer than that.
>> 
> 
> Looks like we only hold the reference to the session cmds, and we track
> the tpg_port_count if there's an established link. But we don't guard or
> deactivate the f_tcm usb function when we unregister the tcm and remove
> the nexus. As far as the host can tell, the device is still connected
> and the function is still active.
> 
> This exists since the beginning. The Fixes tag should have pointed to
> c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
> 
> We can guard against unlinking the port while the gadget_driver is bound
> or we can just deactivate the usb function when that happens. The latter
> is probably a better option.
> 
> BR,
> Thinh

Thanks for the clarification.

I understand your point about "The latter" option: we should deactivate
the USB function when the nexus is dropped to stop new traffic from the
host.

However, even if we implement the deactivation logic in
tcm_usbg_drop_nexus, there could still be a race condition where pending
work items (e.g., bot_cmd_work) are already scheduled but haven't executed
yet.

Therefore, I believe the if (!tv_nexus) checks in this patch are still
necessary as a safeguard to drain pending requests safely without
crashing.

My Proposal:
Can we proceed with this patch (adding the NULL checks and fixing the
Fixes tag) to close the immediate panic? The architectural change to
deactivate the function could then be handled in a separate follow-up
patch, as it might require more extensive testing.

Does that sound reasonable to you?

Best regards,
Jiasheng

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Thinh Nguyen]

On Thu, Feb 19, 2026, Jiasheng Jiang wrote:
> On Thu, 19 Feb 2026 01:30:16 +0000, Thinh Nguyen wrote:
> > On Wed, Feb 18, 2026, Sebastian Andrzej Siewior wrote:
> >> On 2026-02-18 05:22:21 [+0000], Thinh Nguyen wrote:
> >> > > Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
> >> > > Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> >> …
> >> > While the patch itself is fine, we should prevent this situation from
> >> > occurring in the first place. That is, we should enforce the config
> >> > dependency and prevent the users from removing the nexus if the gadget
> >> > driver is bound. Likewise, we should prevent the gadget driver from
> >> > binding if no nexus is established.
> >> 
> >> Is this an actual problem or just something that looks like it could
> >> happen? My memory is that the tcm holds a reference on it and the
> >> referenced commit just split/moved  the code. So if it is a problem then
> >> it should have been there longer than that.
> >> 
> > 
> > Looks like we only hold the reference to the session cmds, and we track
> > the tpg_port_count if there's an established link. But we don't guard or
> > deactivate the f_tcm usb function when we unregister the tcm and remove
> > the nexus. As far as the host can tell, the device is still connected
> > and the function is still active.
> > 
> > This exists since the beginning. The Fixes tag should have pointed to
> > c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
> > 
> > We can guard against unlinking the port while the gadget_driver is bound
> > or we can just deactivate the usb function when that happens. The latter
> > is probably a better option.
> > 
> > BR,
> > Thinh
> 
> Thanks for the clarification.
> 
> I understand your point about "The latter" option: we should deactivate
> the USB function when the nexus is dropped to stop new traffic from the
> host.
> 
> However, even if we implement the deactivation logic in
> tcm_usbg_drop_nexus, there could still be a race condition where pending
> work items (e.g., bot_cmd_work) are already scheduled but haven't executed
> yet.

Yes, we'd need to sync and cancel them properly.

> 
> Therefore, I believe the if (!tv_nexus) checks in this patch are still
> necessary as a safeguard to drain pending requests safely without
> crashing.
> 
> My Proposal:
> Can we proceed with this patch (adding the NULL checks and fixing the
> Fixes tag) to close the immediate panic? The architectural change to
> deactivate the function could then be handled in a separate follow-up
> patch, as it might require more extensive testing.
> 
> Does that sound reasonable to you?

Sounds reasonable to me. As I noted previously, this patch itself is
fine. However, please update your "Fixes" tag to point to the correct
commit. You should also add Cc stable.

Thanks,
Thinh

Re: [PATCH] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Thinh Nguyen]

On Thu, Feb 19, 2026, Jiasheng Jiang wrote:
> The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
> managed and tied to userspace configuration via ConfigFS. It can be
> NULL if the USB host sends requests before the nexus is fully
> established or immediately after it is dropped.
> 
> Currently, functions like `bot_submit_command()` and the data
> transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
> dereference `tv_nexus->tvn_se_sess` without any validation. If a
> malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
> command during this race window, it triggers a NULL pointer
> dereference, leading to a kernel panic (local DoS).
> 
> This exposes an inconsistent API usage within the module, as peer
> functions like `usbg_submit_command()` and `bot_send_bad_response()`
> correctly implement a NULL check for `tv_nexus` before proceeding.
> 
> Fix this by bringing consistency to the nexus handling. Add the
> missing `if (!tv_nexus)` checks to the vulnerable BOT command and
> request processing paths, aborting the command gracefully with an
> error instead of crashing the system.
> 
> Fixes: 08a1cb0f65fd ("usb: gadget: tcm: factor out f_tcm")
> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> ---
>  drivers/usb/gadget/function/f_tcm.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
> index 6e8804f04baa..9554ddd9b4b8 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1222,6 +1222,11 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
>  	se_cmd = &cmd->se_cmd;
>  	tpg = cmd->fu->tpg;
>  	tv_nexus = tpg->tpg_nexus;
> +	if (!tv_nexus) {
> +		pr_err("Missing nexus, ignoring command\n");

Use dev_err.

BR,
Thinh

[PATCH v2] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Jiasheng Jiang]

The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
managed and tied to userspace configuration via ConfigFS. It can be
NULL if the USB host sends requests before the nexus is fully
established or immediately after it is dropped.

Currently, functions like `bot_submit_command()` and the data
transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
dereference `tv_nexus->tvn_se_sess` without any validation. If a
malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
command during this race window, it triggers a NULL pointer
dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer
functions like `usbg_submit_command()` and `bot_send_bad_response()`
correctly implement a NULL check for `tv_nexus` before proceeding.

Fix this by bringing consistency to the nexus handling. Add the
missing `if (!tv_nexus)` checks to the vulnerable BOT command and
request processing paths, aborting the command gracefully with an
error instead of crashing the system.

Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
Cc: stable@vger.kernel.org
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
---
Changelog:

v1 -> v2:

1. Update Fixes tag.
2. Add Cc: stable@vger.kernel.org.
---
 drivers/usb/gadget/function/f_tcm.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
index 6e8804f04baa..9554ddd9b4b8 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1222,6 +1222,11 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
@@ -1482,6 +1487,11 @@ static void bot_cmd_work(struct work_struct *work)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		pr_err("Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
-- 
2.25.1

[PATCH v3] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Jiasheng Jiang]

The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
managed and tied to userspace configuration via ConfigFS. It can be
NULL if the USB host sends requests before the nexus is fully
established or immediately after it is dropped.

Currently, functions like `bot_submit_command()` and the data
transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
dereference `tv_nexus->tvn_se_sess` without any validation. If a
malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
command during this race window, it triggers a NULL pointer
dereference, leading to a kernel panic (local DoS).

This exposes an inconsistent API usage within the module, as peer
functions like `usbg_submit_command()` and `bot_send_bad_response()`
correctly implement a NULL check for `tv_nexus` before proceeding.

Fix this by bringing consistency to the nexus handling. Add the
missing `if (!tv_nexus)` checks to the vulnerable BOT command and
request processing paths, aborting the command gracefully with an
error instead of crashing the system.

Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
Cc: stable@vger.kernel.org
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
---
Changelog:

v2 -> v3:

1. Use dev_err.

v1 -> v2:

1. Update Fixes tag.
2. Add Cc: stable@vger.kernel.org.
---
 drivers/usb/gadget/function/f_tcm.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
index 6e8804f04baa..7b27f8082ace 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1222,6 +1222,13 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		struct usb_gadget *gadget = fuas_to_gadget(cmd->fu);
+
+		dev_err(&gadget->dev, "Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
@@ -1482,6 +1489,13 @@ static void bot_cmd_work(struct work_struct *work)
 	se_cmd = &cmd->se_cmd;
 	tpg = cmd->fu->tpg;
 	tv_nexus = tpg->tpg_nexus;
+	if (!tv_nexus) {
+		struct usb_gadget *gadget = fuas_to_gadget(cmd->fu);
+
+		dev_err(&gadget->dev, "Missing nexus, ignoring command\n");
+		return;
+	}
+
 	dir = get_cmd_dir(cmd->cmd_buf);
 	if (dir < 0)
 		goto out;
-- 
2.25.1

Re: [PATCH v3] usb: gadget: f_tcm: Fix NULL pointer dereferences in nexus handling

[Thinh Nguyen]

On Thu, Feb 19, 2026, Jiasheng Jiang wrote:
> The `tpg->tpg_nexus` pointer in the USB Target driver is dynamically
> managed and tied to userspace configuration via ConfigFS. It can be
> NULL if the USB host sends requests before the nexus is fully
> established or immediately after it is dropped.
> 
> Currently, functions like `bot_submit_command()` and the data
> transfer paths retrieve `tv_nexus = tpg->tpg_nexus` and immediately
> dereference `tv_nexus->tvn_se_sess` without any validation. If a
> malicious or misconfigured USB host sends a BOT (Bulk-Only Transport)
> command during this race window, it triggers a NULL pointer
> dereference, leading to a kernel panic (local DoS).
> 
> This exposes an inconsistent API usage within the module, as peer
> functions like `usbg_submit_command()` and `bot_send_bad_response()`
> correctly implement a NULL check for `tv_nexus` before proceeding.
> 
> Fix this by bringing consistency to the nexus handling. Add the
> missing `if (!tv_nexus)` checks to the vulnerable BOT command and
> request processing paths, aborting the command gracefully with an
> error instead of crashing the system.
> 
> Fixes: c52661d60f63 ("usb-gadget: Initial merge of target module for UASP + BOT")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
> ---
> Changelog:
> 
> v2 -> v3:
> 
> 1. Use dev_err.
> 
> v1 -> v2:
> 
> 1. Update Fixes tag.
> 2. Add Cc: stable@vger.kernel.org.
> ---
>  drivers/usb/gadget/function/f_tcm.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c b/drivers/usb/gadget/function/f_tcm.c
> index 6e8804f04baa..7b27f8082ace 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1222,6 +1222,13 @@ static void usbg_submit_cmd(struct usbg_cmd *cmd)
>  	se_cmd = &cmd->se_cmd;
>  	tpg = cmd->fu->tpg;
>  	tv_nexus = tpg->tpg_nexus;
> +	if (!tv_nexus) {
> +		struct usb_gadget *gadget = fuas_to_gadget(cmd->fu);
> +
> +		dev_err(&gadget->dev, "Missing nexus, ignoring command\n");
> +		return;
> +	}
> +
>  	dir = get_cmd_dir(cmd->cmd_buf);
>  	if (dir < 0)
>  		goto out;
> @@ -1482,6 +1489,13 @@ static void bot_cmd_work(struct work_struct *work)
>  	se_cmd = &cmd->se_cmd;
>  	tpg = cmd->fu->tpg;
>  	tv_nexus = tpg->tpg_nexus;
> +	if (!tv_nexus) {
> +		struct usb_gadget *gadget = fuas_to_gadget(cmd->fu);
> +
> +		dev_err(&gadget->dev, "Missing nexus, ignoring command\n");
> +		return;
> +	}
> +
>  	dir = get_cmd_dir(cmd->cmd_buf);
>  	if (dir < 0)
>  		goto out;
> -- 
> 2.25.1
> 

Reviewed-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>

Thanks,
Thinh