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]
Message-ID: <Pine.LNX.4.64.0702220835370.10496@twin.jikos.cz>
Date:	Thu, 22 Feb 2007 09:04:47 +0100 (CET)
From:	Jiri Kosina <jikos@...os.cz>
To:	Pete Zaitcev <zaitcev@...hat.com>
cc:	vinctre@...eotron.ca, marcel@...tmann.org,
	vincent.fortier1@...gc.ca, linux-kernel@...r.kernel.org
Subject: Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793

On Wed, 21 Feb 2007, Pete Zaitcev wrote:

> Can I get something useful without a kernel recompile, with something 
> like evtest? I have users on Fedora hitting this too. It very likely is 
> a regression caused by the new unified HID.
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755

Hi Pete,

I don't think that this is caused by the newly introduced generic HID 
layer - I can see that both the bugreports in RH bugzilla are reported 
against 2.6.19-1.2895.fc6. I have downloaded the source RPM and discovered 
that these kernels are based on vanilla 2.6.19.2 - these kernels didn't 
have generic HID layer yet, so this can't be the case.

The thing is that hid2hci sends through hiddev some excessivelly large 
value, and HID subsystem then complains about it. It could be that the 
device has a broken report descriptor (*), which results in buggy behavior 
of sw.

It would be really nice to get the report descriptor - Vincent, it wasn't 
in your output. There is a following code in drivers/usb/input/hid-core.c

#ifdef DEBUG_DATA
        printk(KERN_DEBUG __FILE__ ": report descriptor (size %u, read %d) = ", rsize, n);
        for (n = 0; n < rsize; n++)
                printk(" %02x", (unsigned char) rdesc[n]);
        printk("\n");
#endif

Could you make sure that you really compiled this file with 

	#define DEBUG_DATA

so that you get this output upon connection of new USB HID device?

(*) Which looks quite probable to me - I have been playing yesterday with 
another masterpiece from Logitech (S510 keyboard), which also requires 
fixing its report descriptor on-the-fly because it is fully usable :(

-- 
Jiri Kosina
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ