2019-05-27 08:55:01 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-09 13:55:43 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-01 15:35:57 -04:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-12 14:55:12 +01:00
|
|
|
|
2007-11-30 11:12:58 +01:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-25 11:43:31 +01:00
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-05-16 11:49:19 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-09 13:24:25 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-03-09 13:55:43 +01:00
|
|
|
|
|
|
|
|
|
2014-09-08 09:35:35 +02:00
|
|
|
|
2012-03-09 13:55:43 +01:00
|
|
|
|
2024-10-03 07:46:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-23 10:37:04 -04:00
|
|
|
|
2024-10-03 07:46:51 -07:00
|
|
|
|
2025-07-23 10:37:04 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-03 07:46:51 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
2022-09-02 15:29:24 +02:00
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 22:29:55 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2010-12-09 19:29:07 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-24 22:32:29 -05:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-05 00:48:48 +00:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-22 16:03:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:07 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-28 17:06:41 +01:00
|
|
|
|
2022-02-03 15:32:15 +01:00
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-13 16:13:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: kmalloc() -> kmalloc_array()
The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
patch replaces cases of:
kmalloc(a * b, gfp)
with:
kmalloc_array(a * b, gfp)
as well as handling cases of:
kmalloc(a * b * c, gfp)
with:
kmalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kmalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kmalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The tools/ directory was manually excluded, since it has its own
implementation of kmalloc().
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kmalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kmalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kmalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kmalloc
+ kmalloc_array
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kmalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kmalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kmalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kmalloc(sizeof(THING) * C2, ...)
|
kmalloc(sizeof(TYPE) * C2, ...)
|
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(C1 * C2, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * E2
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 13:55:00 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2012-09-17 16:41:56 +05:30
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-14 08:19:22 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2012-09-17 16:41:56 +05:30
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:08 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2010-12-09 19:29:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:07 -08:00
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-14 15:02:56 +02:00
|
|
|
|
2012-05-10 16:45:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-10 16:26:11 -05:00
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
2019-12-10 16:26:11 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2020-12-05 00:48:48 +00:00
|
|
|
|
2010-12-09 19:29:07 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-24 10:04:33 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 15:09:52 +03:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: Fix unit exponent parsing again
Revert some changes done in 774638386826621c984ab6994439f474709cac5e.
Revert all changes done in hidinput_calc_abs_res as it mistakingly used
"Unit" item exponent nibbles to affect resolution value. This wasn't
breaking resolution calculation of relevant axes of any existing
devices, though, as they have only one dimension to their units and thus
1 in the corresponding nible.
Revert to reading "Unit Exponent" item value as a signed integer in
hid_parser_global to fix reading specification-complying values. This
fixes resolution calculation of devices complying to the HID standard,
including Huion, KYE, Waltop and UC-Logic graphics tablets which have
their report descriptors fixed by the drivers.
Explanations follow.
There are two "unit exponents" in HID specification and it is important
not to mix them. One is the global "Unit Exponent" item and another is
nibble values in the global "Unit" item. See 6.2.2.7 Global Items.
The "Unit Exponent" value is just a signed integer and is used to scale
the integer resolution unit values, so fractions can be expressed.
The nibbles of "Unit" value are used to select the unit system (nibble
0), and presence of a particular basic unit type in the unit formula and
its *exponent* (or power, nibbles 1-6). And yes, the latter is in two
complement and zero means absence of the unit type.
Taking the representation example of (integer) joules from the
specification:
[mass(grams)][length(centimeters)^2][time(seconds)^-2] * 10^-7
the "Unit Exponent" would be -7 (or 0xF9, if stored as a byte) and the
"Unit" value would be 0xE121, signifying:
Nibble Part Value Meaning
----- ---- ----- -------
0 System 1 SI Linear
1 Length 2 Centimeters^2
2 Mass 1 Grams
3 Time -2 Seconds^-2
To give the resolution in e.g. hundredth of joules the "Unit Exponent"
item value should have been -9.
See also the examples of "Unit" values for some common units in the same
chapter.
However, there is a common misunderstanding about the "Unit Exponent"
value encoding, where it is assumed to be stored the same as nibbles in
"Unit" item. This is most likely due to the specification being a bit
vague and overloading the term "unit exponent". This also was and still
is proliferated by the official "HID Descriptor Tool", which makes this
mistake and stores "Unit Exponent" as such. This format is also
mentioned in books such as "USB Complete" and in Microsoft's hardware
design guides.
As a result many devices currently on the market use this encoding and
so the driver should support them.
Signed-off-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-13 15:09:52 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-14 16:59:15 +01:00
|
|
|
|
2024-10-03 07:46:51 -07:00
|
|
|
|
2012-11-14 16:59:15 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-03 14:45:59 +08:00
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 22:29:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-24 12:02:22 -04:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2013-07-07 17:43:56 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-24 12:02:22 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
|
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-06 16:49:11 +09:00
|
|
|
|
|
|
|
|
|
2025-06-20 20:02:31 +08:00
|
|
|
|
2025-01-06 16:49:11 +09:00
|
|
|
|
2025-06-20 20:02:31 +08:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-30 15:07:13 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2024-05-22 16:03:28 +08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 22:29:55 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2024-10-01 16:30:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-24 23:05:07 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-31 12:32:39 +08:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2023-10-31 12:32:39 +08:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2023-10-31 12:32:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-03 14:34:20 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
2008-06-18 23:55:41 +02:00
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2024-10-01 08:42:36 -07:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
2012-05-01 08:40:01 +02:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: Improve Windows Precision Touchpad detection.
Per Microsoft spec, usage 0xC5 (page 0xFF) returns a blob containing
data used to verify the touchpad as a Windows Precision Touchpad.
0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA)
0x09, 0xC5, // USAGE (Vendor Usage 0xC5)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff)
0x75, 0x08, // REPORT_SIZE (8)
0x96, 0x00, 0x01, // REPORT_COUNT (0x100 (256))
0xb1, 0x02, // FEATURE (Data,Var,Abs)
However, some devices, namely Microsoft's Surface line of products
instead implement a "segmented device certification report" (usage 0xC6)
which returns the same report, but in smaller chunks.
0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined)
0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA)
0x09, 0xC6, // USAGE (Vendor usage for segment #)
0x25, 0x08, // LOGICAL_MAXIMUM (8)
0x75, 0x08, // REPORT_SIZE (8)
0x95, 0x01, // REPORT_COUNT (1)
0xb1, 0x02, // FEATURE (Data,Var,Abs)
0x09, 0xC7, // USAGE (Vendor Usage)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff)
0x95, 0x20, // REPORT_COUNT (32)
0xb1, 0x02, // FEATURE (Data,Var,Abs)
By expanding Win8 touchpad detection to also look for the segmented
report, all Surface touchpads are now properly recognized by
hid-multitouch.
Signed-off-by: Blaž Hrastnik <blaz@mxxn.io>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2019-11-06 20:02:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:08 +02:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-12-12 10:17:26 -08:00
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
2023-01-11 10:07:36 +00:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
2014-11-03 18:26:12 -08:00
|
|
|
|
|
|
|
|
|
2017-01-19 06:32:09 -05:00
|
|
|
|
2014-11-03 18:26:12 -08:00
|
|
|
|
|
|
|
|
|
2014-12-12 10:17:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 15:03:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 22:21:39 +08:00
|
|
|
|
2019-03-27 11:18:48 +01:00
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-31 13:27:10 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:08 +02:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
2024-08-03 14:34:20 +02:00
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
|
|
|
|
|
2025-08-21 16:38:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-22 14:51:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-24 12:52:23 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-30 13:18:23 -04:00
|
|
|
|
2017-04-11 11:10:16 +02:00
|
|
|
|
2014-12-12 10:17:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-09 13:15:37 +02:00
|
|
|
|
2014-09-30 13:18:23 -04:00
|
|
|
|
2014-07-24 12:52:23 -07:00
|
|
|
|
|
|
|
|
|
2018-07-13 16:13:50 +02:00
|
|
|
|
2013-08-22 14:51:07 +02:00
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-22 20:00:12 +08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-03 14:34:18 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-22 20:00:12 +08:00
|
|
|
|
2013-09-11 21:56:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 15:29:24 +02:00
|
|
|
|
2013-09-11 21:56:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: core: fix validation of report id 0
Some drivers use the first HID report in the list instead of using an
index. In these cases, validation uses ID 0, which was supposed to mean
"first known report". This fixes the problem, which was causing at least
the lgff family of devices to stop working since hid_validate_values
was being called with ID 0, but the devices used single numbered IDs
for their reports:
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x05, /* Usage (Gamepad), */
0xA1, 0x01, /* Collection (Application), */
0xA1, 0x02, /* Collection (Logical), */
0x85, 0x01, /* Report ID (1), */
...
Cc: stable@vger.kernel.org
Reported-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-04-17 13:22:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-16 11:11:24 +00:00
|
|
|
|
|
|
|
|
|
HID: core: fix validation of report id 0
Some drivers use the first HID report in the list instead of using an
index. In these cases, validation uses ID 0, which was supposed to mean
"first known report". This fixes the problem, which was causing at least
the lgff family of devices to stop working since hid_validate_values
was being called with ID 0, but the devices used single numbered IDs
for their reports:
0x05, 0x01, /* Usage Page (Desktop), */
0x09, 0x05, /* Usage (Gamepad), */
0xA1, 0x01, /* Collection (Application), */
0xA1, 0x02, /* Collection (Logical), */
0x85, 0x01, /* Report ID (1), */
...
Cc: stable@vger.kernel.org
Reported-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-04-17 13:22:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-11 21:56:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
|
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
2019-01-09 13:50:18 +10:00
|
|
|
|
2024-12-31 14:23:12 -05:00
|
|
|
|
|
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2024-08-03 14:34:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
HID: core: Fix deadloop in hid_apply_multiplier.
The initial value of hid->collection[].parent_idx if 0. When
Report descriptor doesn't contain "HID Collection", the value
remains as 0.
In the meanwhile, when the Report descriptor fullfill
all following conditions, it will trigger hid_apply_multiplier
function call.
1. Usage page is Generic Desktop Ctrls (0x01)
2. Usage is RESOLUTION_MULTIPLIER (0x48)
3. Contain any FEATURE items
The while loop in hid_apply_multiplier will search the top-most
collection by searching parent_idx == -1. Because all parent_idx
is 0. The loop will run forever.
There is a Report Descriptor triggerring the deadloop
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x48, // Usage (0x48)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0xB1, 0x01, // Feature
Signed-off-by: Xin Zhao <xnzhao@google.com>
Link: https://lore.kernel.org/r/20230130212947.1315941-1-xnzhao@google.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-01-30 21:29:47 +00:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2024-10-01 16:30:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-01 16:30:07 +02:00
|
|
|
|
|
|
|
|
|
2024-10-01 16:30:06 +02:00
|
|
|
|
|
|
|
|
|
2012-09-20 12:00:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-01 16:30:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-20 12:00:32 -07:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:04 -08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2018-08-29 10:22:09 -05:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
Convert remaining multi-line kmalloc_obj/flex GFP_KERNEL uses
Conversion performed via this Coccinelle script:
// SPDX-License-Identifier: GPL-2.0-only
// Options: --include-headers-for-types --all-includes --include-headers --keep-comments
virtual patch
@gfp depends on patch && !(file in "tools") && !(file in "samples")@
identifier ALLOC = {kmalloc_obj,kmalloc_objs,kmalloc_flex,
kzalloc_obj,kzalloc_objs,kzalloc_flex,
kvmalloc_obj,kvmalloc_objs,kvmalloc_flex,
kvzalloc_obj,kvzalloc_objs,kvzalloc_flex};
@@
ALLOC(...
- , GFP_KERNEL
)
$ make coccicheck MODE=patch COCCI=gfp.cocci
Build and boot tested x86_64 with Fedora 42's GCC and Clang:
Linux version 6.19.0+ (user@host) (gcc (GCC) 15.2.1 20260123 (Red Hat 15.2.1-7), GNU ld version 2.44-12.fc42) #1 SMP PREEMPT_DYNAMIC 1970-01-01
Linux version 6.19.0+ (user@host) (clang version 20.1.8 (Fedora 20.1.8-4.fc42), LLD 20.1.8) #1 SMP PREEMPT_DYNAMIC 1970-01-01
Signed-off-by: Kees Cook <kees@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 23:46:04 -08:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: core: Fix deadloop in hid_apply_multiplier.
The initial value of hid->collection[].parent_idx if 0. When
Report descriptor doesn't contain "HID Collection", the value
remains as 0.
In the meanwhile, when the Report descriptor fullfill
all following conditions, it will trigger hid_apply_multiplier
function call.
1. Usage page is Generic Desktop Ctrls (0x01)
2. Usage is RESOLUTION_MULTIPLIER (0x48)
3. Contain any FEATURE items
The while loop in hid_apply_multiplier will search the top-most
collection by searching parent_idx == -1. Because all parent_idx
is 0. The loop will run forever.
There is a Report Descriptor triggerring the deadloop
0x05, 0x01, // Usage Page (Generic Desktop Ctrls)
0x09, 0x48, // Usage (0x48)
0x95, 0x01, // Report Count (1)
0x75, 0x08, // Report Size (8)
0xB1, 0x01, // Feature
Signed-off-by: Xin Zhao <xnzhao@google.com>
Link: https://lore.kernel.org/r/20230130212947.1315941-1-xnzhao@google.com
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-01-30 21:29:47 +00:00
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2019-08-23 21:15:27 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-28 13:29:54 +02:00
|
|
|
|
2007-03-12 14:55:12 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2018-12-05 10:42:23 +10:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-23 21:15:27 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2018-08-28 13:29:54 +02:00
|
|
|
|
2018-08-29 10:22:09 -05:00
|
|
|
|
2007-03-12 14:55:12 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-05 14:44:05 +02:00
|
|
|
|
2019-08-12 09:20:22 -06:00
|
|
|
|
|
|
|
|
|
2019-06-05 14:44:05 +02:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2015-05-30 11:00:26 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-06 10:19:58 -07:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-06 10:19:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-06 10:19:58 -07:00
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2016-04-06 10:19:58 -07:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-04-06 10:19:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2016-01-18 22:40:37 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:05 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-22 20:00:12 +08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-01 21:47:11 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:10 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:15 +01:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
2015-05-30 11:00:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:16 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:15 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2022-02-03 15:32:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:22 +01:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:22 +01:00
|
|
|
|
|
|
|
|
|
2022-07-01 13:27:20 +02:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
2022-02-03 15:32:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
2022-02-03 15:32:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-29 12:26:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.
This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.
This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.
I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().
All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.
Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-10 19:56:27 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-29 12:26:01 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.
This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.
This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.
I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().
All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.
Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-10 19:56:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-10 16:01:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.
This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.
This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.
I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().
All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.
Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-10 19:56:27 +02:00
|
|
|
|
|
|
|
|
|
2025-07-10 16:01:33 +02:00
|
|
|
|
HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.
This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.
This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.
I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().
All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.
Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-10 19:56:27 +02:00
|
|
|
|
2024-10-29 15:44:35 +01:00
|
|
|
|
HID: fix data access in implement()
implement() is setting bytes in LE data stream. In case the data is not
aligned to 64bits, it reads past the allocated buffer. It doesn't really
change any value there (it's properly bitmasked), but in case that this
read past the boundary hits a page boundary, pagefault happens when
accessing 64bits of 'x' in implement(), and kernel oopses.
This happens much more often when numbered reports are in use, as the
initial 8bit skip in the buffer makes the whole process work on values
which are not aligned to 64bits.
This problem dates back to attempts in 2005 and 2006 to make implement()
and extract() as generic as possible, and even back then the problem
was realized by Adam Kroperlin, but falsely assumed to be impossible
to cause any harm:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg47690.html
I have made several attempts at fixing it "on the spot" directly in
implement(), but the results were horrible; the special casing for processing
last 64bit chunk and switching to different math makes it unreadable mess.
I therefore took a path to allocate a few bytes more which will never make
it into final report, but are there as a cushion for all the 64bit math
operations happening in implement() and extract().
All callers of hid_output_report() are converted at the same time to allocate
the buffer by newly introduced hid_alloc_report_buf() helper.
Bruno noticed that the whole raw_size test can be dropped as well, as
hid_alloc_report_buf() makes sure that the buffer is always of a proper
size.
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-10 19:56:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 22:32:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2009-06-12 15:20:57 +02:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-15 11:00:38 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:40:53 +01:00
|
|
|
|
2006-12-08 18:40:44 +01:00
|
|
|
|
2024-07-05 11:17:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-03 16:20:20 +02:00
|
|
|
|
2022-09-02 15:29:25 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
HID: core: ensure __hid_request reserves the report ID as the first byte
The low level transport driver expects the first byte to be the report
ID, even when the report ID is not use (in which case they just shift
the buffer).
However, __hid_request() whas not offsetting the buffer it used by one
in this case, meaning that the raw_request() callback emitted by the
transport driver would be stripped of the first byte.
Note: this changes the API for uhid devices when a request is made
through hid_hw_request. However, several considerations makes me think
this is fine:
- every request to a HID device made through hid_hw_request() would see
that change, but every request made through hid_hw_raw_request()
already has the new behaviour. So that means that the users are
already facing situations where they might have or not the first byte
being the null report ID when it is 0. We are making things more
straightforward in the end.
- uhid is mainly used for BLE devices
- uhid is also used for testing, but I don't see that change a big issue
- for BLE devices, we can check which kernel module is calling
hid_hw_request()
- and in those modules, we can check which are using a Bluetooth device
- and then we can check if the command is used with a report ID or not.
- surprise: none of the kernel module are using a report ID 0
- and finally, bluez, in its function set_report()[0], does the same
shift if the report ID is 0 and the given buffer has a size > 0.
[0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43
Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-10 16:01:34 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
2018-01-08 10:41:41 +08:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-03 16:20:20 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
HID: core: ensure __hid_request reserves the report ID as the first byte
The low level transport driver expects the first byte to be the report
ID, even when the report ID is not use (in which case they just shift
the buffer).
However, __hid_request() whas not offsetting the buffer it used by one
in this case, meaning that the raw_request() callback emitted by the
transport driver would be stripped of the first byte.
Note: this changes the API for uhid devices when a request is made
through hid_hw_request. However, several considerations makes me think
this is fine:
- every request to a HID device made through hid_hw_request() would see
that change, but every request made through hid_hw_raw_request()
already has the new behaviour. So that means that the users are
already facing situations where they might have or not the first byte
being the null report ID when it is 0. We are making things more
straightforward in the end.
- uhid is mainly used for BLE devices
- uhid is also used for testing, but I don't see that change a big issue
- for BLE devices, we can check which kernel module is calling
hid_hw_request()
- and in those modules, we can check which are using a Bluetooth device
- and then we can check if the command is used with a report ID or not.
- surprise: none of the kernel module are using a report ID 0
- and finally, bluez, in its function set_report()[0], does the same
shift if the report ID is 0 and the given buffer has a size > 0.
[0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43
Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-10 16:01:34 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
HID: core: ensure __hid_request reserves the report ID as the first byte
The low level transport driver expects the first byte to be the report
ID, even when the report ID is not use (in which case they just shift
the buffer).
However, __hid_request() whas not offsetting the buffer it used by one
in this case, meaning that the raw_request() callback emitted by the
transport driver would be stripped of the first byte.
Note: this changes the API for uhid devices when a request is made
through hid_hw_request. However, several considerations makes me think
this is fine:
- every request to a HID device made through hid_hw_request() would see
that change, but every request made through hid_hw_raw_request()
already has the new behaviour. So that means that the users are
already facing situations where they might have or not the first byte
being the null report ID when it is 0. We are making things more
straightforward in the end.
- uhid is mainly used for BLE devices
- uhid is also used for testing, but I don't see that change a big issue
- for BLE devices, we can check which kernel module is calling
hid_hw_request()
- and in those modules, we can check which are using a Bluetooth device
- and then we can check if the command is used with a report ID or not.
- surprise: none of the kernel module are using a report ID 0
- and finally, bluez, in its function set_report()[0], does the same
shift if the report ID is 0 and the given buffer has a size > 0.
[0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43
Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-10 16:01:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
HID: core: ensure __hid_request reserves the report ID as the first byte
The low level transport driver expects the first byte to be the report
ID, even when the report ID is not use (in which case they just shift
the buffer).
However, __hid_request() whas not offsetting the buffer it used by one
in this case, meaning that the raw_request() callback emitted by the
transport driver would be stripped of the first byte.
Note: this changes the API for uhid devices when a request is made
through hid_hw_request. However, several considerations makes me think
this is fine:
- every request to a HID device made through hid_hw_request() would see
that change, but every request made through hid_hw_raw_request()
already has the new behaviour. So that means that the users are
already facing situations where they might have or not the first byte
being the null report ID when it is 0. We are making things more
straightforward in the end.
- uhid is mainly used for BLE devices
- uhid is also used for testing, but I don't see that change a big issue
- for BLE devices, we can check which kernel module is calling
hid_hw_request()
- and in those modules, we can check which are using a Bluetooth device
- and then we can check if the command is used with a report ID or not.
- surprise: none of the kernel module are using a report ID 0
- and finally, bluez, in its function set_report()[0], does the same
shift if the report ID is 0 and the given buffer has a size > 0.
[0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43
Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Fixes: 4fa5a7f76cc7 ("HID: core: implement generic .request()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2025-07-10 16:01:34 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
2025-07-10 16:01:35 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-03 16:20:20 +02:00
|
|
|
|
|
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
2019-04-03 16:20:20 +02:00
|
|
|
|
2014-02-10 12:58:48 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 15:29:24 +02:00
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-31 17:22:23 +01:00
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
2018-01-08 10:41:41 +08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2012-04-27 00:56:08 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2012-04-27 00:56:08 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
|
|
|
|
|
2020-08-29 12:26:01 +01:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-19 21:41:22 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-27 00:56:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
2013-09-11 21:56:57 +02:00
|
|
|
|
2022-02-03 15:32:17 +01:00
|
|
|
|
2013-01-31 17:22:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-28 16:53:11 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-27 00:56:08 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:32 +02:00
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2009-07-19 17:26:13 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2011-08-10 14:02:59 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-19 17:26:13 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2024-06-26 15:46:32 +02:00
|
|
|
|
2022-11-03 16:57:47 +01:00
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2022-11-03 16:57:47 +01:00
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2012-06-28 16:53:11 +02:00
|
|
|
|
2013-04-17 19:38:13 +02:00
|
|
|
|
|
|
|
|
|
2012-06-28 16:53:11 +02:00
|
|
|
|
2010-03-18 14:11:53 +01:00
|
|
|
|
|
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-18 14:11:53 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2013-10-08 19:33:47 +02:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2012-04-27 00:56:08 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
|
|
|
|
|
2011-08-10 14:02:59 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
2024-06-26 15:46:32 +02:00
|
|
|
|
2024-06-26 15:46:30 +02:00
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
2006-12-08 18:41:17 +01:00
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:41 +01:00
|
|
|
|
|
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
2012-04-23 12:07:04 +02:00
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:41 +01:00
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-30 15:25:45 +02:00
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
|
|
|
|
|
2008-08-27 11:19:37 +02:00
|
|
|
|
|
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-23 22:50:18 -05:00
|
|
|
|
|
|
|
|
|
2024-12-02 20:01:32 +01:00
|
|
|
|
2024-12-02 20:01:33 +01:00
|
|
|
|
2024-12-02 20:01:32 +01:00
|
|
|
|
2011-01-23 22:50:18 -05:00
|
|
|
|
2015-12-27 17:25:24 +08:00
|
|
|
|
2015-12-27 17:25:21 +08:00
|
|
|
|
2011-01-23 22:50:18 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
2024-12-02 20:01:32 +01:00
|
|
|
|
|
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
2015-12-27 17:25:21 +08:00
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-02 20:01:33 +01:00
|
|
|
|
2011-01-23 22:50:18 -05:00
|
|
|
|
2024-12-02 20:01:32 +01:00
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-18 16:31:33 -07:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
2011-01-23 22:50:18 -05:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
2022-11-03 16:57:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-16 17:19:50 +01:00
|
|
|
|
|
|
|
|
|
2010-07-12 19:28:27 +02:00
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
2008-08-20 19:13:52 +02:00
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-21 16:56:54 +02:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-23 12:08:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-20 11:49:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-03 15:32:21 +01:00
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-03 17:54:01 +09:00
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-17 17:02:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-16 19:49:07 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-03 17:39:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-09 18:50:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-27 00:04:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-15 16:27:45 +02:00
|
|
|
|
|
|
|
|
|
2015-02-17 14:00:03 +01:00
|
|
|
|
2009-09-15 16:27:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-03 15:33:32 -05:00
|
|
|
|
2022-11-03 16:57:47 +01:00
|
|
|
|
|
|
|
|
|
2009-09-15 16:27:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-05 17:41:13 +09:00
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-11 14:39:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-11 14:39:05 +01:00
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
2025-02-11 14:39:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 15:29:25 +02:00
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 14:39:50 +02:00
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:25 +02:00
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:25 +02:00
|
|
|
|
2024-06-26 15:46:26 +02:00
|
|
|
|
2024-06-26 15:46:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 15:29:25 +02:00
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
2024-06-26 15:46:26 +02:00
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 14:39:50 +02:00
|
|
|
|
2024-06-26 15:46:28 +02:00
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
2024-06-26 15:46:28 +02:00
|
|
|
|
HID: core: Provide new max_buffer_size attribute to over-ride the default
Presently, when a report is processed, its proposed size, provided by
the user of the API (as Report Size * Report Count) is compared against
the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
low-level HID drivers allocate a reduced amount of memory to their
buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
this check inadequate in some cases.
In these circumstances, if the received report ends up being smaller
than the proposed report size, the remainder of the buffer is zeroed.
That is, the space between sizeof(csize) (size of the current report)
and the rsize (size proposed i.e. Report Size * Report Count), which can
be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
shoots straight past the end of the buffer boundary and starts zeroing
out in-use values, often resulting in calamity.
This patch introduces a new variable into 'struct hid_ll_driver' where
individual low-level drivers can over-ride the default maximum value of
HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
interface.
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2023-01-23 12:39:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-26 15:46:28 +02:00
|
|
|
|
2021-12-02 10:53:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-02 10:53:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-26 14:34:44 +00:00
|
|
|
|
2020-09-22 20:00:12 +08:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-09 11:03:04 +02:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
2015-12-27 17:25:22 +08:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 13:34:41 -05:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-09 11:03:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
|
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
2024-07-01 14:07:37 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2015-12-27 17:25:22 +08:00
|
|
|
|
2015-12-27 17:25:21 +08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2012-04-23 12:07:05 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2018-07-17 22:35:36 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-06 11:20:54 +03:00
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-01 16:30:12 +02:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
2024-10-01 16:30:12 +02:00
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
2025-08-21 16:38:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2025-08-21 16:38:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-21 16:38:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "HID: bpf: allow write access to quirks field in struct hid_device"
This reverts commit 6fd47effe92b, and the related self-test update
commit e14e0eaeb040 ("selftests/hid: add test for assigning a given
device to hid-generic").
It results in things like the scroll wheel on Logitech mice not working
after a reboot due to the kernel being confused about the state of the
high-resolution mode.
Quoting Benjamin Tissoires:
"The idea of 6fd47effe92b was to be able to call hid_bpf_rdesc_fixup()
once per reprobe of the device.
However, because the bpf filter can now change the quirk value, the
call had to be moved before the driver gets bound (which was
previously ensuring the unicity of the call).
The net effect is that now, in the case hid-generic gets loaded first
and then the specific driver gets loaded once the disk is available,
the value of ->quirks is not reset, but kept to the value that was set
by hid-generic (HID_QUIRK_INPUT_PER_APP).
Once hid-logitech-hidpp kicks in, that quirk is now set, which creates
two inputs for the single mouse: one keyboard for fancy shortcuts, and
one mouse node.
However, hid-logitech-hidpp expects only one input node to be attached
(it stores it into hidpp->input), and when a wheel event is received,
because there is some processing with high-resolution wheel events,
the wheel event is injected into hidpp->input.
And of course, when HID_QUIRK_INPUT_PER_APP is set, hidpp->input gets
the keyboard node, which doesn't have wheel event type, and the events
are ignored"
Reported-and-bisected-by: Mike Galbraith <efault@gmx.de>
Link: https://lore.kernel.org/all/CAHk-=wiUkQM3uheit2cNM0Y0OOY5qqspJgC8LkmOkJ2p2LDxcw@mail.gmail.com/
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-25 09:21:21 -08:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
2023-05-23 14:04:32 -07:00
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2015-12-27 17:25:21 +08:00
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
2018-05-31 13:49:29 +02:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
HID: Separate struct hid_device's driver_lock into two locks.
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).
Historically, three functions used driver_lock:
- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock
This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:
- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock
This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.
This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-18 09:20:21 -08:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:31 -07:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-13 21:35:22 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2015-12-27 17:25:21 +08:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2021-03-19 17:27:16 -07:00
|
|
|
|
HID: Separate struct hid_device's driver_lock into two locks.
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).
Historically, three functions used driver_lock:
- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock
This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:
- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock
This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.
This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-18 09:20:21 -08:00
|
|
|
|
2011-08-10 14:02:07 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:16 +02:00
|
|
|
|
|
|
|
|
|
2023-05-23 14:04:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: Separate struct hid_device's driver_lock into two locks.
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).
Historically, three functions used driver_lock:
- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock
This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:
- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock
This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.
This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-18 09:20:21 -08:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-19 08:46:27 -07:00
|
|
|
|
2015-11-14 22:08:08 +01:00
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2013-08-23 14:24:38 -07:00
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2013-08-23 14:24:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2024-12-02 20:01:33 +01:00
|
|
|
|
2024-12-02 20:01:32 +01:00
|
|
|
|
2015-11-19 08:19:31 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-30 05:54:38 +02:00
|
|
|
|
2015-11-19 08:19:31 -08:00
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:02 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-20 08:38:46 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2013-08-23 14:24:38 -07:00
|
|
|
|
2017-06-09 11:03:04 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:41 +01:00
|
|
|
|
2008-05-16 11:49:20 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:41 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:20 +02:00
|
|
|
|
|
|
|
|
|
2012-12-06 12:39:55 -02:00
|
|
|
|
2008-05-16 11:49:20 +02:00
|
|
|
|
|
|
|
|
|
2014-02-20 15:24:49 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-21 16:38:13 +02:00
|
|
|
|
2012-04-23 12:07:03 +02:00
|
|
|
|
2022-09-02 15:29:23 +02:00
|
|
|
|
|
|
|
|
|
HID: struct device - replace bus_id with dev_name(), dev_set_name()
This patch is part of a larger patch series which will remove
the "char bus_id[20]" name string from struct device. The device
name is managed in the kobject anyway, and without any size
limitation, and just needlessly copied into "struct device".
To set and read the device name dev_name(dev) and dev_set_name(dev)
must be used. If your code uses static kobjects, which it shouldn't
do, "const char *init_name" can be used to statically provide the
name the registered device should have. At registration time, the
init_name field is cleared, to enforce the use of dev_name(dev) to
access the device name at a later time.
We need to get rid of all occurrences of bus_id in the entire tree
to be able to enable the new interface. Please apply this patch,
and possibly convert any remaining remaining occurrences of bus_id.
We want to submit a patch to -next, which will remove bus_id from
"struct device", to find the remaining pieces to convert, and finally
switch over to the new api, which will remove the 20 bytes array
and does no longer have a size limitation.
CC: Jiri Kosina <jkosina@suse.cz>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2008-10-31 00:12:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 15:29:23 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2010-03-15 14:55:40 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-15 14:55:40 +01:00
|
|
|
|
|
|
|
|
|
2009-06-12 15:20:55 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-24 14:06:31 +08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2009-06-12 15:20:57 +02:00
|
|
|
|
|
|
|
|
|
HID: debug: fix RCU preemption issue
Commit 2353f2bea ("HID: protect hid_debug_list") introduced mutex
locking around debug_list access to prevent SMP races when debugfs
nodes are being operated upon by multiple userspace processess.
mutex is not a proper synchronization primitive though, as the hid-debug
callbacks are being called from atomic contexts.
We also have to be careful about disabling IRQs when taking the lock
to prevent deadlock against IRQ handlers.
Benjamin reports this has also been reported in RH bugzilla as bug #958935.
===============================
[ INFO: suspicious RCU usage. ]
3.9.0+ #94 Not tainted
-------------------------------
include/linux/rcupdate.h:476 Illegal context switch in RCU read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
4 locks held by Xorg/5502:
#0: (&evdev->mutex){+.+...}, at: [<ffffffff81512c3d>] evdev_write+0x6d/0x160
#1: (&(&dev->event_lock)->rlock#2){-.-...}, at: [<ffffffff8150dd9b>] input_inject_event+0x5b/0x230
#2: (rcu_read_lock){.+.+..}, at: [<ffffffff8150dd82>] input_inject_event+0x42/0x230
#3: (&(&usbhid->lock)->rlock){-.....}, at: [<ffffffff81565289>] usb_hidinput_input_event+0x89/0x120
stack backtrace:
CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
0000000000000001 ffff8800689c7c38 ffffffff816f249f ffff8800689c7c68
ffffffff810acb1d 0000000000000000 ffffffff81a03ac7 000000000000019d
0000000000000000 ffff8800689c7c90 ffffffff8107cda7 0000000000000000
Call Trace:
[<ffffffff816f249f>] dump_stack+0x19/0x1b
[<ffffffff810acb1d>] lockdep_rcu_suspicious+0xfd/0x130
[<ffffffff8107cda7>] __might_sleep+0xc7/0x230
[<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
[<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
[<ffffffff81553cc4>] hid_debug_event+0x34/0x100
[<ffffffff81554197>] hid_dump_input+0x67/0xa0
[<ffffffff81556430>] hid_set_field+0x50/0x120
[<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
[<ffffffff8150d89e>] input_handle_event+0x8e/0x530
[<ffffffff8150df10>] input_inject_event+0x1d0/0x230
[<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
[<ffffffff81512cae>] evdev_write+0xde/0x160
[<ffffffff81185038>] vfs_write+0xc8/0x1f0
[<ffffffff81185535>] SyS_write+0x55/0xa0
[<ffffffff81704482>] system_call_fastpath+0x16/0x1b
BUG: sleeping function called from invalid context at kernel/mutex.c:413
in_atomic(): 1, irqs_disabled(): 1, pid: 5502, name: Xorg
INFO: lockdep is turned off.
irq event stamp: 1098574
hardirqs last enabled at (1098573): [<ffffffff816fb53f>] _raw_spin_unlock_irqrestore+0x3f/0x70
hardirqs last disabled at (1098574): [<ffffffff816faaf5>] _raw_spin_lock_irqsave+0x25/0xa0
softirqs last enabled at (1098306): [<ffffffff8104971f>] __do_softirq+0x18f/0x3c0
softirqs last disabled at (1097867): [<ffffffff81049ad5>] irq_exit+0xa5/0xb0
CPU: 0 PID: 5502 Comm: Xorg Not tainted 3.9.0+ #94
Hardware name: Dell Inc. OptiPlex 390/0M5DCD, BIOS A09 07/24/2012
ffffffff81a03ac7 ffff8800689c7c68 ffffffff816f249f ffff8800689c7c90
ffffffff8107ce60 0000000000000000 ffff8800689c7fd8 ffff88006a62c800
ffff8800689c7d10 ffffffff816f7770 ffff8800689c7d00 ffffffff81312ac4
Call Trace:
[<ffffffff816f249f>] dump_stack+0x19/0x1b
[<ffffffff8107ce60>] __might_sleep+0x180/0x230
[<ffffffff816f7770>] mutex_lock_nested+0x40/0x3a0
[<ffffffff81312ac4>] ? vsnprintf+0x354/0x640
[<ffffffff81553cc4>] hid_debug_event+0x34/0x100
[<ffffffff81554197>] hid_dump_input+0x67/0xa0
[<ffffffff81556430>] hid_set_field+0x50/0x120
[<ffffffff8156529a>] usb_hidinput_input_event+0x9a/0x120
[<ffffffff8150d89e>] input_handle_event+0x8e/0x530
[<ffffffff8150df10>] input_inject_event+0x1d0/0x230
[<ffffffff8150dd82>] ? input_inject_event+0x42/0x230
[<ffffffff81512cae>] evdev_write+0xde/0x160
[<ffffffff81185038>] vfs_write+0xc8/0x1f0
[<ffffffff81185535>] SyS_write+0x55/0xa0
[<ffffffff81704482>] system_call_fastpath+0x16/0x1b
Reported-by: majianpeng <majianpeng@gmail.com>
Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 13:05:50 +02:00
|
|
|
|
HID: Separate struct hid_device's driver_lock into two locks.
This patch separates struct hid_device's driver_lock into two. The
goal is to allow hid device drivers to receive input during their
probe() or remove() function calls. This is necessary because some
drivers need to communicate with the device to determine parameters
needed during probe (e.g., size of a multi-touch surface), and if
possible, may perfer to communicate with a device on host-initiated
disconnect (e.g., to put it into a low-power state).
Historically, three functions used driver_lock:
- hid_device_probe: blocks to acquire lock
- hid_device_remove: blocks to acquire lock
- hid_input_report: if locked returns -EBUSY, else acquires lock
This patch adds another lock (driver_input_lock) which is used to
block input from occurring. The lock behavior is now:
- hid_device_probe: blocks to acq. driver_lock, then driver_input_lock
- hid_device_remove: blocks to acq. driver_lock, then driver_input_lock
- hid_input_report: if driver_input_lock locked returns -EBUSY, else
acquires driver_input_lock
This patch also adds two helper functions to be called during probe()
or remove(): hid_device_io_start() and hid_device_io_stop(). These
functions lock and unlock, respectively, driver_input_lock; they also
make a note of whether they did so that hid-core knows if a driver has
changed the lock state.
This patch results in no behavior change for existing devices and
drivers. However, during a probe() or remove() function call in a
driver, that driver may now selectively call hid_device_io_start() to
let input events come through, then optionally call
hid_device_io_stop() to stop them.
Signed-off-by: Andrew de los Reyes <adlr@chromium.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-02-18 09:20:21 -08:00
|
|
|
|
2017-06-06 23:59:34 -07:00
|
|
|
|
2023-10-31 12:32:39 +08:00
|
|
|
|
2009-06-12 15:20:57 +02:00
|
|
|
|
2024-06-26 15:46:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2024-06-26 15:46:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-12 15:20:55 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2012-04-22 14:21:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HID: bpf: move HID-BPF report descriptor fixup earlier
Currently, hid_bpf_rdesc_fixup() is called once the match between the
HID device and the driver is done. This can be problematic in case
the driver selected by the kernel would change the report descriptor
after the fact.
To give a chance for hid_bpf_rdesc_fixup() to provide hints on to how
to select a dedicated driver or not, move the call to that BPF hook
earlier in the .probe() process, when we get the first match.
However, this means that we might get called more than once (typically
once for hid-generic, and once for hid-vendor-specific). So we store the
result of HID-BPF fixup in struct hid_device. Basically, this means that
->bpf_rdesc can replace ->dev_rdesc when it was used in the code.
In order to not grow struct hid_device, some fields are re-ordered. This
was the output of pahole for the first 128 bytes:
struct hid_device {
__u8 * dev_rdesc; /* 0 8 */
unsigned int dev_rsize; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
__u8 * rdesc; /* 16 8 */
unsigned int rsize; /* 24 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_collection * collection; /* 32 8 */
unsigned int collection_size; /* 40 4 */
unsigned int maxcollection; /* 44 4 */
unsigned int maxapplication; /* 48 4 */
__u16 bus; /* 52 2 */
__u16 group; /* 54 2 */
__u32 vendor; /* 56 4 */
__u32 product; /* 60 4 */
/* --- cacheline 1 boundary (64 bytes) --- */
__u32 version; /* 64 4 */
enum hid_type type; /* 68 4 */
unsigned int country; /* 72 4 */
/* XXX 4 bytes hole, try to pack */
struct hid_report_enum report_enum[3]; /* 80 6216 */
Basically, we got three holes of 4 bytes. We can reorder things a little
and makes those 3 holes a continuous 12 bytes hole, which can be replaced
by the new pointer and the new unsigned int we need.
In terms of code allocation, when not using HID-BPF, we are back to kernel
v6.2 in hid_open_report(). These multiple kmemdup() calls will be fixed
in a later commit.
Link: https://patch.msgid.link/20241001-hid-bpf-hid-generic-v3-1-2ef1019468df@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
2024-10-01 16:30:05 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-31 13:49:29 +02:00
|
|
|
|
|
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
2017-12-08 15:29:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-24 16:20:09 +01:00
|
|
|
|
2017-11-20 11:48:44 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-17 15:38:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-02 00:02:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-17 15:38:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2024-11-27 17:41:56 +01:00
|
|
|
|
2022-11-03 16:57:49 +01:00
|
|
|
|
2024-06-26 15:46:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-09 19:29:03 -08:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2024-06-08 11:01:13 +02:00
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-12 15:20:55 +02:00
|
|
|
|
|
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2024-06-08 11:01:13 +02:00
|
|
|
|
2022-11-03 16:57:44 +01:00
|
|
|
|
2009-06-12 15:20:55 +02:00
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
2008-05-16 11:49:15 +02:00
|
|
|
|
2017-11-20 11:48:41 +01:00
|
|
|
|
2007-05-14 09:57:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-02 18:29:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-04 15:10:23 -07:00
|
|
|
|
2017-01-05 11:07:04 -08:00
|
|
|
|
