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:	Fri, 28 Oct 2011 18:40:20 -0200
From:	Denilson Figueiredo de Sá <denilsonsa@...il.com>
To:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
	"Jiri Kosina" <jkosina@...e.cz>
Cc:	"Christoph Fritz" <chf.fritz@...glemail.com>,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: Linux USB HID should ignore values outside Logical
 Minimum/Maximum range

On Fri, 28 Oct 2011 14:23:17 -0200, Jiri Kosina <jkosina@...e.cz> wrote:

> On the other hand I feel like just dropping the report on the floor  
> should be the proper thing to do.

I'd say not the entire report, but just the invalid fields.

The HID specification (HID1_11.pdf) talks about "Null Values" at the  
section 5.10 (page 20).

[quote]
HID class devices support the ability to ignore selected fields in a  
report at run-
time. This is accomplished by declaring bit field in a report that is  
capable of
containing a range of values larger than those actually generated by the  
control. If
the host or the device receives an out-of-range value then the current  
value for the
respective control will not be modified.
[/quote]


(sidenote: Why didn't I mention this spec earlier? Because I knew I have  
read that information somewhere, but didn't find it again until today.)


> Christoph, how about the (untested at my side yet) patch below? It'd be
> nice if you could test with the device you are seeing the problem with  
> and let me know.

I can't test it *right now*, but I can probably test it in a week or two.


> +	/* Ignore absolute values that are out of bounds */
> +	if ((usage->type == EV_ABS && (value < field->logical_minimum ||
> +					value > field->logical_maximum))) {

Given what the HID spec says (as I quoted above), I'd change this  
condition to just:

> +	if (value < field->logical_minimum ||
> +					value > field->logical_maximum) {

On the other hand, HID spec also defines the "Null" bit of Input fields at  
page 31. This Null bit seems redundant for me, as (in my understanding)  
any value outside the range is automatically a null value. We wouldn't  
need a Null bit for that.

Anyway, another solution is to change that condition to something like  
this:

> +	if ( THIS_INPUT_FIELD_HAS_NULL_BIT_SET &&
> +                      (value < field->logical_minimum ||
> +					value > field->logical_maximum)) {

What do you think?


-- 
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
--
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