Add a sanity check on the device id-table driver_info field to make sure
we never access a type structure (and function pointers) outside of the
device info array (e.g. if someone fails to ifdef a device-id entry).

Note that this also suppresses a compiler warning with -Warray-bounds
(gcc-11.3.0) when compile-testing the driver without enabling any of
the device type Kconfig options:

    drivers/input/touchscreen/usbtouchscreen.c: In function 'usbtouch_probe':
    drivers/input/touchscreen/usbtouchscreen.c:1668:16:warning: array subscript <unknown> is outside array bounds of 'struct usbtouch_device_info[0]' [-Warray-bounds]
     1668 |         type = &usbtouch_dev_info[id->driver_info];

Signed-off-by: Johan Hovold <johan@kernel.org>
---

Changes in v2
 - use ARRAY_SIZE() for the sanity check (Dmitry)
 - drop the dummy entry and combine the two patches as the sanity check
   itself is enough to suppress the compiler warning (Dmitry)
 - use -ENODEV instead of -EINVAL even if this means no error will be
   logged in the unlikely event of a future driver bug


 drivers/input/touchscreen/usbtouchscreen.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
index 43c521f50c85..b01d026588c8 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -1654,6 +1654,9 @@ static int usbtouch_probe(struct usb_interface *intf,
 	if (id->driver_info == DEVTYPE_IGNORE)
 		return -ENODEV;
 
+	if (id->driver_info >= ARRAY_SIZE(usbtouch_dev_info))
+                return -ENODEV;
+
 	endpoint = usbtouch_get_input_endpoint(intf->cur_altsetting);
 	if (!endpoint)
 		return -ENXIO;
-- 
2.35.1

On Thu, Jun 23, 2022 at 08:24:46AM +0200, Johan Hovold wrote:
> Add a sanity check on the device id-table driver_info field to make sure
> we never access a type structure (and function pointers) outside of the
> device info array (e.g. if someone fails to ifdef a device-id entry).
> 
> Note that this also suppresses a compiler warning with -Warray-bounds
> (gcc-11.3.0) when compile-testing the driver without enabling any of
> the device type Kconfig options:
> 
>     drivers/input/touchscreen/usbtouchscreen.c: In function 'usbtouch_probe':
>     drivers/input/touchscreen/usbtouchscreen.c:1668:16:warning: array subscript <unknown> is outside array bounds of 'struct usbtouch_device_info[0]' [-Warray-bounds]
>      1668 |         type = &usbtouch_dev_info[id->driver_info];
> 
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> 
> Changes in v2
>  - use ARRAY_SIZE() for the sanity check (Dmitry)
>  - drop the dummy entry and combine the two patches as the sanity check
>    itself is enough to suppress the compiler warning (Dmitry)
>  - use -ENODEV instead of -EINVAL even if this means no error will be
>    logged in the unlikely event of a future driver bug

Is this on purpose or because I happened to have used this error code
when I suggested the change? I'm fine with returning -EINVAL there.

Thanks.

-- 
Dmitry

On Thu, Jun 23, 2022 at 08:59:52AM -0700, Dmitry Torokhov wrote:
> On Thu, Jun 23, 2022 at 08:24:46AM +0200, Johan Hovold wrote:
> > Add a sanity check on the device id-table driver_info field to make sure
> > we never access a type structure (and function pointers) outside of the
> > device info array (e.g. if someone fails to ifdef a device-id entry).
> > 
> > Note that this also suppresses a compiler warning with -Warray-bounds
> > (gcc-11.3.0) when compile-testing the driver without enabling any of
> > the device type Kconfig options:
> > 
> >     drivers/input/touchscreen/usbtouchscreen.c: In function 'usbtouch_probe':
> >     drivers/input/touchscreen/usbtouchscreen.c:1668:16:warning: array subscript <unknown> is outside array bounds of 'struct usbtouch_device_info[0]' [-Warray-bounds]
> >      1668 |         type = &usbtouch_dev_info[id->driver_info];
> > 
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> > 
> > Changes in v2
> >  - use ARRAY_SIZE() for the sanity check (Dmitry)
> >  - drop the dummy entry and combine the two patches as the sanity check
> >    itself is enough to suppress the compiler warning (Dmitry)
> >  - use -ENODEV instead of -EINVAL even if this means no error will be
> >    logged in the unlikely event of a future driver bug
> 
> Is this on purpose or because I happened to have used this error code
> when I suggested the change? I'm fine with returning -EINVAL there.

It was on purpose. Returning -EINVAL (invalid argument) here just
doesn't seem quite right. I skimmed the errno list for a better
alternative, but decided -ENODEV works as well.

If there's ever a driver bug that triggers this, you could say the
device isn't supported in that configuration. ;)

If you prefer -EINVAL, I'll change it back.

Johan

On Mon, Jun 27, 2022 at 09:46:27AM +0200, Johan Hovold wrote:
> On Thu, Jun 23, 2022 at 08:59:52AM -0700, Dmitry Torokhov wrote:
> > On Thu, Jun 23, 2022 at 08:24:46AM +0200, Johan Hovold wrote:
> > > Add a sanity check on the device id-table driver_info field to make sure
> > > we never access a type structure (and function pointers) outside of the
> > > device info array (e.g. if someone fails to ifdef a device-id entry).
> > > 
> > > Note that this also suppresses a compiler warning with -Warray-bounds
> > > (gcc-11.3.0) when compile-testing the driver without enabling any of
> > > the device type Kconfig options:
> > > 
> > >     drivers/input/touchscreen/usbtouchscreen.c: In function 'usbtouch_probe':
> > >     drivers/input/touchscreen/usbtouchscreen.c:1668:16:warning: array subscript <unknown> is outside array bounds of 'struct usbtouch_device_info[0]' [-Warray-bounds]
> > >      1668 |         type = &usbtouch_dev_info[id->driver_info];
> > > 
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > > 
> > > Changes in v2
> > >  - use ARRAY_SIZE() for the sanity check (Dmitry)
> > >  - drop the dummy entry and combine the two patches as the sanity check
> > >    itself is enough to suppress the compiler warning (Dmitry)
> > >  - use -ENODEV instead of -EINVAL even if this means no error will be
> > >    logged in the unlikely event of a future driver bug
> > 
> > Is this on purpose or because I happened to have used this error code
> > when I suggested the change? I'm fine with returning -EINVAL there.
> 
> It was on purpose. Returning -EINVAL (invalid argument) here just
> doesn't seem quite right. I skimmed the errno list for a better
> alternative, but decided -ENODEV works as well.
> 
> If there's ever a driver bug that triggers this, you could say the
> device isn't supported in that configuration. ;)
> 
> If you prefer -EINVAL, I'll change it back.

No, that is fine, I was simply making sure. Applied, thank you.

-- 
Dmitry