[PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Hongbo Li]

Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
typec: ucsi: skip connector validation before init") add the bounds
check when do the connector change both in pre-init notification and
the forward notifications. But they are difficult to backport to
early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
Instead, we choose to validate connector number in ucsi_connector_change
directly to avoid out-of-range issue.

Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API")
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
---
 drivers/usb/typec/ucsi/ucsi.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index b88f4e179a7a..4f5a72a1fbd8 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -960,13 +960,20 @@ static void ucsi_handle_connector_change(struct work_struct *work)
  */
 void ucsi_connector_change(struct ucsi *ucsi, u8 num)
 {
-	struct ucsi_connector *con = &ucsi->connector[num - 1];
+	struct ucsi_connector *con;
 
 	if (!(ucsi->ntfy & UCSI_ENABLE_NTFY_CONNECTOR_CHANGE)) {
 		dev_dbg(ucsi->dev, "Early connector change event\n");
 		return;
 	}
 
+	if (ucsi->cap.num_connectors && num > ucsi->cap.num_connectors) {
+		dev_err(ucsi->dev, "bogus connector number in CCI: %u\n",
+			num);
+		return;
+	}
+	con = &ucsi->connector[num - 1];
+
 	if (!test_and_set_bit(EVENT_PENDING, &ucsi->flags))
 		schedule_work(&con->work);
 }
-- 
2.34.1

Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Greg KH]

On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
> Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
> number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
> typec: ucsi: skip connector validation before init") add the bounds
> check when do the connector change both in pre-init notification and
> the forward notifications. But they are difficult to backport to
> early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
> Instead, we choose to validate connector number in ucsi_connector_change
> directly to avoid out-of-range issue.

Why just these 2 branches?

And what specific commits are needed exactly?  Why not just backport
them all?  that will make future changes apply properly as well, making
the overall work much less over time.

thanks,

greg k-h

Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Hongbo Li]

Hi Greg,

On 2026/5/8 19:03, Greg KH wrote:
> On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
>> Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
>> number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
>> typec: ucsi: skip connector validation before init") add the bounds
>> check when do the connector change both in pre-init notification and
>> the forward notifications. But they are difficult to backport to
>> early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
>> Instead, we choose to validate connector number in ucsi_connector_change
>> directly to avoid out-of-range issue.
> 
> Why just these 2 branches?

I only noticed these two branches, but in fact, there are more.

> 
> And what specific commits are needed exactly?  Why not just backport
> them all?  that will make future changes apply properly as well, making

Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector number in 
ucsi_notify_common()") use the ucsi_notify_common helper which is 
introduced in 584e8df58942 ("usb: typec: ucsi: extract common code for 
command handling"). This commit refactored part of the code and involves 
many modifications to USB ucsi controllers (such as stm32g0...), which 
were introduced after 6.6.

I think there are two possible modifications:
One is to adapt the modification for different branches, and the other 
is to modify the code in ucsi_connector_change (as in my commit).

Thanks,
Hongbo

> the overall work much less over time.
> 
> thanks,
> 
> greg k-h
> 

Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Greg KH]

On Fri, May 08, 2026 at 08:59:06PM +0800, Hongbo Li wrote:
> Hi Greg,
> 
> On 2026/5/8 19:03, Greg KH wrote:
> > On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
> > > Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
> > > number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
> > > typec: ucsi: skip connector validation before init") add the bounds
> > > check when do the connector change both in pre-init notification and
> > > the forward notifications. But they are difficult to backport to
> > > early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
> > > Instead, we choose to validate connector number in ucsi_connector_change
> > > directly to avoid out-of-range issue.
> > 
> > Why just these 2 branches?
> 
> I only noticed these two branches, but in fact, there are more.
> 
> > 
> > And what specific commits are needed exactly?  Why not just backport
> > them all?  that will make future changes apply properly as well, making
> 
> Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector number in
> ucsi_notify_common()") use the ucsi_notify_common helper which is introduced
> in 584e8df58942 ("usb: typec: ucsi: extract common code for command
> handling"). This commit refactored part of the code and involves many
> modifications to USB ucsi controllers (such as stm32g0...), which were
> introduced after 6.6.

So just 2 commits?  that's nothing, we have taken hundreds of commits of
backports in the past.  Please try to stick to what is exactly upstream,
it is easier for everyone overall.

thanks,

greg k-h

Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Hongbo Li]

Hi Greg,

On 2026/5/8 21:04, Greg KH wrote:
> On Fri, May 08, 2026 at 08:59:06PM +0800, Hongbo Li wrote:
>> Hi Greg,
>>
>> On 2026/5/8 19:03, Greg KH wrote:
>>> On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
>>>> Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
>>>> number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
>>>> typec: ucsi: skip connector validation before init") add the bounds
>>>> check when do the connector change both in pre-init notification and
>>>> the forward notifications. But they are difficult to backport to
>>>> early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
>>>> Instead, we choose to validate connector number in ucsi_connector_change
>>>> directly to avoid out-of-range issue.
>>>
>>> Why just these 2 branches?
>>
>> I only noticed these two branches, but in fact, there are more.
>>
>>>
>>> And what specific commits are needed exactly?  Why not just backport
>>> them all?  that will make future changes apply properly as well, making
>>
>> Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector number in
>> ucsi_notify_common()") use the ucsi_notify_common helper which is introduced
>> in 584e8df58942 ("usb: typec: ucsi: extract common code for command
>> handling"). This commit refactored part of the code and involves many
>> modifications to USB ucsi controllers (such as stm32g0...), which were
>> introduced after 6.6.
> 
> So just 2 commits?  that's nothing, we have taken hundreds of commits of

No. This is not an issue of the number of backport patches.

For commit 584e8df58942, it refractored the logic based on a higher 
version (higher than 6.6) which introduced new ucsi controllers 
(yoga_c630 for 6.6, yoga_c630, glink and stm32g0 for 5.10). So we should 
remove some extra code and resolve conflicts if we backport this patch 
to the target branch like the first way I mentioned.

But I looked at the modification logic of the commit d2d8c17ac01a and 
commit 5a1140404cbf, and I think it can be made simpler (like the patch 
I post), of course, this requires the maintainer to help review it.

And we need Krogerus and Rebello to take a look.

Thanks,
Hongbo

> backports in the past.  Please try to stick to what is exactly upstream,
> it is easier for everyone overall.
> 
> thanks,
> 
> greg k-h
> 

Re: [PATCH 6.6 & 5.10] usb: typec: ucsi: validate connector number in ucsi_connector_change

[Greg KH]

On Sat, May 09, 2026 at 11:32:08AM +0800, Hongbo Li wrote:
> Hi Greg,
> 
> On 2026/5/8 21:04, Greg KH wrote:
> > On Fri, May 08, 2026 at 08:59:06PM +0800, Hongbo Li wrote:
> > > Hi Greg,
> > > 
> > > On 2026/5/8 19:03, Greg KH wrote:
> > > > On Fri, May 08, 2026 at 05:20:26PM +0800, Hongbo Li wrote:
> > > > > Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector
> > > > > number in ucsi_notify_common()") and commit 5a1140404cbf ("usb:
> > > > > typec: ucsi: skip connector validation before init") add the bounds
> > > > > check when do the connector change both in pre-init notification and
> > > > > the forward notifications. But they are difficult to backport to
> > > > > early stable branch such as LTS 6.6, LTS 5.10 due to many dependencies.
> > > > > Instead, we choose to validate connector number in ucsi_connector_change
> > > > > directly to avoid out-of-range issue.
> > > > 
> > > > Why just these 2 branches?
> > > 
> > > I only noticed these two branches, but in fact, there are more.
> > > 
> > > > 
> > > > And what specific commits are needed exactly?  Why not just backport
> > > > them all?  that will make future changes apply properly as well, making
> > > 
> > > Commit d2d8c17ac01a ("usb: typec: ucsi: validate connector number in
> > > ucsi_notify_common()") use the ucsi_notify_common helper which is introduced
> > > in 584e8df58942 ("usb: typec: ucsi: extract common code for command
> > > handling"). This commit refactored part of the code and involves many
> > > modifications to USB ucsi controllers (such as stm32g0...), which were
> > > introduced after 6.6.
> > 
> > So just 2 commits?  that's nothing, we have taken hundreds of commits of
> 
> No. This is not an issue of the number of backport patches.
> 
> For commit 584e8df58942, it refractored the logic based on a higher version
> (higher than 6.6) which introduced new ucsi controllers (yoga_c630 for 6.6,
> yoga_c630, glink and stm32g0 for 5.10). So we should remove some extra code
> and resolve conflicts if we backport this patch to the target branch like
> the first way I mentioned.
> 
> But I looked at the modification logic of the commit d2d8c17ac01a and commit
> 5a1140404cbf, and I think it can be made simpler (like the patch I post), of
> course, this requires the maintainer to help review it.
> 
> And we need Krogerus and Rebello to take a look.

There is no requirement for any maintainers to deal with stable
backports if they do not want to.  As you feel you are stuck with these
old kernel versions, I suggest you make up the patch series and post
them for review, as you can test them the best.

thanks,

greg k-h