kernel/linux.git/drivers/input/tablet/gtco.c, branch v5.4.232

Input: gtco - fix endpoint sanity check

2020-01-29T15:45:28+00:00

commit a8eeb74df5a6bdb214b2b581b14782c5f5a0cf83 upstream. The driver was checking the number of endpoints of the first alternate setting instead of the current one, something which could lead to the driver binding to an invalid interface. This in turn could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: 162f98dea487 ("Input: gtco - fix crash on detecting device without endpoints") Signed-off-by: Johan Hovold Acked-by: Vladis Dronov Link: https://lore.kernel.org/r/20191210113737.4016-5-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: gtco - bounds check collection indent level

2019-07-13T08:43:10+00:00

The GTCO tablet input driver configures itself from an HID report sent via USB during the initial enumeration process. Some debugging messages are generated during the parsing. A debugging message indentation counter is not bounds checked, leading to the ability for a specially crafted HID report to cause '-' and null bytes be written past the end of the indentation array. As long as the kernel has CONFIG_DYNAMIC_DEBUG enabled, this code will not be optimized out. This was discovered during code review after a previous syzkaller bug was found in this driver. Signed-off-by: Grant Hernandez Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: gtco - fix potential out-of-bound access

2017-10-27T22:14:41+00:00

parse_hid_report_descriptor() has a while (i < length) loop, which only guarantees that there's at least 1 byte in the buffer, but the loop body can read multiple bytes which causes out-of-bounds access. Reported-by: Andrey Konovalov Reviewed-by: Andrey Konovalov Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Replace with globally

2016-12-24T19:46:01+00:00

This was entirely automated, using the script by Al: PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*' sed -i -e "s!$PATT!#include !" \ $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h) to do the replacement at the end of the merge window. Requested-by: Al Viro Signed-off-by: Linus Torvalds

Merge branch 'next' into for-linus

2016-05-17T00:25:08+00:00

Prepare first round of input updates for 4.7 merge window.

Input: gtco - stop saving struct usb_device

2016-03-31T20:13:41+00:00

The device can now easily be derived from the interface. Stop leaving a private copy. Signed-off-by: Oliver Neukum Signed-off-by: Dmitry Torokhov

Input: gtco - fix crash on detecting device without endpoints

2016-03-31T20:10:00+00:00

The gtco driver expects at least one valid endpoint. If given malicious descriptors that specify 0 for the number of endpoints, it will crash in the probe function. Ensure there is at least one endpoint on the interface before using it. Also let's fix a minor coding style issue. The full correct report of this issue can be found in the public Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1283385 Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov

Input: gtco - use sign_extend32() for sign extension

2015-01-27T07:07:45+00:00

Signed-off-by: Martin Kepplinger Signed-off-by: Dmitry Torokhov

Input: gtco - fix usb_dev leak

2014-01-28T06:34:49+00:00

There is usb_get_dev() in gtco_probe(), but there is no usb_put_dev() anywhere in the driver. As pointed out by Dmitry Torokhov: The lifetime of gtco structure is already directly tied to lifetime of usb_dev: when destroying usb_dev driver core will call remove() function of currently bound driver (in our case gtco) which will destroy gtco memory. Taking additional reference is not needed here. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Signed-off-by: Dmitry Torokhov

Input: delete non-required instances of include

2014-01-07T07:23:57+00:00

None of these files are actually using any __init type directives and hence don't need to include . Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by: Paul Gortmaker Signed-off-by: Dmitry Torokhov