This patch intended to fix an well-knonw issue in old drivers where the
endpoint type is taken for granted, which is often triggered by fuzzers.
That was the case for this driver [1], and although the fix seems to be
correct, it uncovered another issue that leads to a regression [2] if
the endpoints of the current interface are checked. The driver makes use
of endpoints that belong to a different interface rather than the one it
binds (it binds to the third interface, but also accesses an endpoint
from a different one). The driver should claim the interfaces it
requires, but that is still not the case.
Given that the regression is more severe than the issue found by
syzkaller, the best approach is reverting the patch that causes the
regression, and trying to fix the underlying problem before checking
the endpoint types again.
Note that reverting this patch will probably trigger the syzkaller bug
at some point.
[1] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
[2] https://lore.kernel.org/linux-input/[email protected]/T/#t
This reverts commit 2b9c3eb32a699acdd4784d6b93743271b4970899.
Fixes: b516b1b0dfcc ("Revert "Input: bcm5974 - check endpoint type before starting traffic"")
Signed-off-by: Javier Carrasco <[email protected]>
---
drivers/input/mouse/bcm5974.c | 20 --------------------
1 file changed, 20 deletions(-)
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index 953992b458e9..ca150618d32f 100644
--- a/drivers/input/mouse/bcm5974.c
+++ b/drivers/input/mouse/bcm5974.c
@@ -19,7 +19,6 @@
* Copyright (C) 2006 Nicolas Boichat ([email protected])
*/
-#include "linux/usb.h"
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/slab.h>
@@ -194,8 +193,6 @@ enum tp_type {
/* list of device capability bits */
#define HAS_INTEGRATED_BUTTON 1
-/* maximum number of supported endpoints (currently trackpad and button) */
-#define MAX_ENDPOINTS 2
/* trackpad finger data block size */
#define FSIZE_TYPE1 (14 * sizeof(__le16))
@@ -894,18 +891,6 @@ static int bcm5974_resume(struct usb_interface *iface)
return error;
}
-static bool bcm5974_check_endpoints(struct usb_interface *iface,
- const struct bcm5974_config *cfg)
-{
- u8 ep_addr[MAX_ENDPOINTS + 1] = {0};
-
- ep_addr[0] = cfg->tp_ep;
- if (cfg->tp_type == TYPE1)
- ep_addr[1] = cfg->bt_ep;
-
- return usb_check_int_endpoints(iface, ep_addr);
-}
-
static int bcm5974_probe(struct usb_interface *iface,
const struct usb_device_id *id)
{
@@ -918,11 +903,6 @@ static int bcm5974_probe(struct usb_interface *iface,
/* find the product index */
cfg = bcm5974_get_config(udev);
- if (!bcm5974_check_endpoints(iface, cfg)) {
- dev_err(&iface->dev, "Unexpected non-int endpoint\n");
- return -ENODEV;
- }
-
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(struct bcm5974), GFP_KERNEL);
input_dev = input_allocate_device();
---
base-commit: 90d35da658da8cff0d4ecbb5113f5fac9d00eb72
change-id: 20240305-revert_bcm5974_ep_check-37f2a6ab2714
Best regards,
--
Javier Carrasco <[email protected]>
On 05.03.24 06:52, Javier Carrasco wrote:
> This patch intended to fix an well-knonw issue in old drivers where the
> endpoint type is taken for granted, which is often triggered by fuzzers.
>
> That was the case for this driver [1], and although the fix seems to be
> correct, it uncovered another issue that leads to a regression [2] if
> the endpoints of the current interface are checked. The driver makes use
> of endpoints that belong to a different interface rather than the one it
> binds (it binds to the third interface, but also accesses an endpoint
> from a different one). The driver should claim the interfaces it
> requires, but that is still not the case.
>
> Given that the regression is more severe than the issue found by
> syzkaller, the best approach is reverting the patch that causes the
> regression, and trying to fix the underlying problem before checking
> the endpoint types again.
>
> Note that reverting this patch will probably trigger the syzkaller bug
> at some point.
>> [1] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
> [2] https://lore.kernel.org/linux-input/[email protected]/T/#t
FWIW, these should be Link: or Closes tags, as explained in the docs.
And there is a better lore link. And there is the bugzilla entry as well.
Hence...
> This reverts commit 2b9c3eb32a699acdd4784d6b93743271b4970899.
>
> Fixes: b516b1b0dfcc ("Revert "Input: bcm5974 - check endpoint type before starting traffic"")
you might want to add them here like this:
Link: https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 [1]
Link: https://lore.kernel.org/linux-input/[email protected]/ [2]
Link: https://bugzilla.suse.com/show_bug.cgi?id=1220030
In an ideal world we also would add a "Reported-by: Jacopo Radice" before
the bugzilla line, as the details in the suse bugtracker apparently is
public, but it's likely better to not go down that path.
> Signed-off-by: Javier Carrasco <[email protected]>
Ciao, Thorsten
On 05.03.24 07:20, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 05.03.24 06:52, Javier Carrasco wrote:
>> This patch intended to fix an well-knonw issue in old drivers where the
>> endpoint type is taken for granted, which is often triggered by fuzzers.
>>
>> That was the case for this driver [1], and although the fix seems to be
>> correct, it uncovered another issue that leads to a regression [2] if
>> the endpoints of the current interface are checked. The driver makes use
>> of endpoints that belong to a different interface rather than the one it
>> binds (it binds to the third interface, but also accesses an endpoint
>> from a different one). The driver should claim the interfaces it
>> requires, but that is still not the case.
>>
>> Given that the regression is more severe than the issue found by
>> syzkaller, the best approach is reverting the patch that causes the
>> regression, and trying to fix the underlying problem before checking
>> the endpoint types again.
>>
>> Note that reverting this patch will probably trigger the syzkaller bug
>> at some point.
>>> [1] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622
>> [2] https://lore.kernel.org/linux-input/[email protected]/T/#t
>
> FWIW, these should be Link: or Closes tags, as explained in the docs.
> And there is a better lore link. And there is the bugzilla entry as well.
> Hence...
>
>> This reverts commit 2b9c3eb32a699acdd4784d6b93743271b4970899.
>>
>> Fixes: b516b1b0dfcc ("Revert "Input: bcm5974 - check endpoint type before starting traffic"")
>
> you might want to add them here like this:
>
> Link: https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 [1]
> Link: https://lore.kernel.org/linux-input/[email protected]/ [2]
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1220030
>
> In an ideal world we also would add a "Reported-by: Jacopo Radice" before
> the bugzilla line, as the details in the suse bugtracker apparently is
> public, but it's likely better to not go down that path.
>
>> Signed-off-by: Javier Carrasco <[email protected]>
>
> Ciao, Thorsten
Thanks for your comments, I will apply those changes right away and add
the "Repported-by:" tag as well.
Best regards,
Javier Carrasco