Re: [PATCH 1/2] usb: typec: ucsi: validate connector number in ucsi_connector_change()

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Mar 11, 2026 at 05:49:36PM -0400, Nathan Rebello wrote:
> On Wed, 11 Mar 2026 at 14:10:28 +0100, Greg KH wrote:
> > Shouldn't this return an error and have the caller stop what it was
> > attempted to do?  When this is called in ucsi_init(), the
> > num_connectors is already parsed, so how can this be wrong?  Shouldn't
> > these values all be verified in one single place and then if any of the
> > descriptors are "incorrect", the device rejected at that point in time
> > and not require "deep" changes in the logic here to try to find these
> > types of errors?
> >
> > in short, let's validate the device once, and after that is done, we can
> > "trust" that it is correct and not need to check this stuff all over the
> > place.
> 
> The CCI connector number can't be validated at init because it's not a
> static descriptor -- it arrives fresh with each runtime interrupt from
> the CCI register. The device can correctly report num_connectors=2 at
> init time, then later send an interrupt with connector_number=50 in the
> CCI. This is the same class of issue already handled at line 1840 in
> ucsi_init(), where buggy firmware sets a reserved bit in num_connectors
> and a defensive check was added because it "happens in buggy FW."
> 
> Without a bounds check, an out-of-range connector number indexes past
> the connector array into adjacent heap memory, and the resulting pointer
> is passed to schedule_work() -- dereferencing whatever function pointer
> happens to sit at that offset. A single buggy interrupt could crash the
> kernel.
> 
> The closest single validation point is ucsi_notify_common(), the sole
> entry point where the CCI is parsed before calling
> ucsi_connector_change(). A one-line bounds check there would cover all
> backends and all call sites.
> 
> Happy to send a v2 with that approach if acceptable.

Yes, please do that as we need central points where data is validated to
help keep the code sane.

thanks,

greg k-h