From: Konrad Dybcio <konradybcio@kernel.org>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
usb4-upstream@oss.qualcomm.com,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Subject: [PATCH RFC] usb: typec: bus: Don't set state->alt when exiting altmode
Date: Tue, 31 Mar 2026 17:20:24 +0200 [thread overview]
Message-ID: <20260331-topic-usb_mux_null-v1-1-7cfa4f5164bc@oss.qualcomm.com> (raw)
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Currently, typec_altmode_enter/exit() and typec_remove() make a call to
typec_altmode_set_state(adev, TYPEC_STATE_SAFE, NULL) in order to
configure the chained muxes/retimers appropriately.
The drivers for those retimers and muxes however, almost unilaterally
trust that if state->alt is set, we're *entering* an alternate mode.
This may lead to NULL pointer dereferences, since most drivers would
then check the (still set) state->alt->svid and proceed to dereference
state->data. which is NULL in this call site. This on top of the fact
that the SAFE configuration wouldn't take place due to th
aforementioned assumption.
Stop sending these mixed signals.
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
Sending this as an RFC. The other option would be to go through all
the mux/retimer drivers and add additional if (state >= MODAL) checks.
LMK which one is preferred.
---
drivers/usb/typec/bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/bus.c b/drivers/usb/typec/bus.c
index e84b134a3381..3423f6f35b22 100644
--- a/drivers/usb/typec/bus.c
+++ b/drivers/usb/typec/bus.c
@@ -21,7 +21,7 @@ typec_altmode_set_retimer(struct altmode *alt, unsigned long conf, void *data)
if (!alt->retimer)
return 0;
- state.alt = &alt->adev;
+ state.alt = conf >= TYPEC_STATE_MODAL ? &alt->adev : NULL;
state.mode = conf;
state.data = data;
@@ -36,7 +36,7 @@ typec_altmode_set_mux(struct altmode *alt, unsigned long conf, void *data)
if (!alt->mux)
return 0;
- state.alt = &alt->adev;
+ state.alt = conf >= TYPEC_STATE_MODAL ? &alt->adev : NULL;
state.mode = conf;
state.data = data;
---
base-commit: e77a5a5cfe43b4c25bd44a3818e487033287517f
change-id: 20260331-topic-usb_mux_null-2cf93662d48e
Best regards,
--
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
reply other threads:[~2026-03-31 15:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260331-topic-usb_mux_null-v1-1-7cfa4f5164bc@oss.qualcomm.com \
--to=konradybcio@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=usb4-upstream@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox