linux-kernel - Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Apr 2007 13:18:31 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Vincent ETIENNE <ve@...ienne.net>
Cc:	Alan Stern <stern@...land.harvard.edu>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	linux-usb-devel@...ts.sourceforge.net,
	Paul Walmsley <paul@...yaka.com>
Subject: Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in
 linux-2.6.21-rc6-mm1)

On Sat, 28 Apr 2007, Vincent ETIENNE wrote:

> > No, it isn't a problem in the USB core.  The device itself is messed up;
> > it really does report idVendor and idProduct both equal to 0.
> So is it just a scary trace but without consequence that i could ignored 
> ? May i ask you what is the device which is messed up ? ( Maybe should i 
> change it ? )

Hi Vincent,

yes, the device is messed up, but it shouldn't have any consequences for 
you - the HID driver is able to correctly handle that, so as soon as we 
don't need to add any extra quirks for such device, everything should be 
fine. I have removed the WARN_ON from the code in my tree. I think we 
still don't want users to add quirks for such broken devices (as it would 
collide with hid_blakclist[] terminator), so I have left the initial 
condition in usbhid_modify_dquirk() untouched.


From: Jiri Kosina <jkosina@...e.cz>

USB HID: don't warn on idVendor == 0

It turns out that there are broken devices out there that incorrectly
report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496

Therefore we should not confuse users by dumping warnings and stacktraces
in such situation. It is not possible to add quirks for such horribly
broken devices, but currently that's not needed.

Signed-off-by: Jiri Kosina <jkosina@...e.cz>

diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 27188bd..17a8755 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis
 	struct quirks_list_struct *q;
 	struct hid_blacklist *bl_entry = NULL;
 
-	WARN_ON(idVendor == 0);
-
 	list_for_each_entry(q, &dquirks_list, node) {
 		if (q->hid_bl_item.idVendor == idVendor &&
 				q->hid_bl_item.idProduct == idProduct) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/