Re: [PATCH 5.4 17/78] HID: Fix slab-out-of-bounds read in hid_field_extract (Broken!)

[peter enderborg]

On 2/5/20 10:54 AM, Jiri Kosina wrote:
> On Wed, 5 Feb 2020, Enderborg, Peter wrote:
>
>>>> This patch breaks Elgato StreamDeck.
>>> Does that mean the device is broken with a too-large of a report?
>> Yes.
> In which way does the breakage pop up? Are you getting "report too long" 
> errors in dmesg, or the device just doesn't enumerate at all?
>
> Could you please post /sys/kernel/debug/hid/<device>/rdesc contents, and 
> if the device is at least semi-alive, also contents of 
> /sys/kernel/debug/hid/<device>/events from the time it misbehaves?
>
Sure.

[ÂÂ 18.710500] hid-generic 0003:0FD9:0060.0005: report is too long
[ÂÂ 18.716511] hid-generic 0003:0FD9:0060.0005: item 0 1 0 9 parsing failed
[ÂÂ 18.723359] hid-generic: probe of 0003:0FD9:0060.0005 failed with error -22
[root@imx ~]# cat /sys/kernel/debug/hid/0003\:0FD9\:0060.0005/rdesc
05 0c 09 01 a1 01 09 01 05 09 19 01 29 10 15 00 26 ff 00 75 08 95 10 85 01 81 02 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 a0 81 02 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 a1 81 02 0a 00 ff 15 00 26 ff 00 75 08 96 fe 1f 85 02 91 02 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 03 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 04 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 05 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 01 85 06 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 07 b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 01 85 08 b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 09 b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 0a b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 0b b1 04 c0 c0

The rdesc is different in 5.3.16 and quite long where it works. The head is there:

[root@imx ~]# cat rdesc.5.3.16 | more
05 0c 09 01 a1 01 09 01 05 09 19 01 29 10 15 00 26 ff 00 75 08 95 10 85 01 81 02
Â0a 00 ff 15 00 26 ff 00 75 08 95 10 85 a0 81 02 0a 00 ff 15 00 26 ff 00 75 08 9
5 10 85 a1 81 02 0a 00 ff 15 00 26 ff 00 75 08 96 fe 1f 85 02 91 02 a1 00 0a 00
ff 15 00 26 ff 00 75 08 95 10 85 03 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08
Â95 10 85 04 b1 02 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 05 b1 02 c0 a
1 00 0a 00 ff 15 00 26 ff 00 75 08 95 01 85 06 b1 02 c0 a1 00 0a 00 ff 15 00 26
ff 00 75 08 95 10 85 07 b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 01 85 08
Âb1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08 95 10 85 09 b1 04 c0 a1 00 0a 00 f
f 15 00 26 ff 00 75 08 95 10 85 0a b1 04 c0 a1 00 0a 00 ff 15 00 26 ff 00 75 08
95 10 85 0b b1 04 c0 c0

 INPUT(1)[INPUT]
ÂÂÂ Field(0)
ÂÂÂÂÂ Application(Consumer.0001)
ÂÂÂÂÂ Usage(17)
ÂÂÂÂÂÂÂ Consumer.0001
ÂÂÂÂÂÂÂ Button.0001
ÂÂÂÂÂÂÂ Button.0002
ÂÂÂÂÂÂÂ Button.0003
ÂÂÂÂÂÂÂ Button.0004
ÂÂÂÂÂÂÂ Button.0005
ÂÂÂÂÂÂÂ Button.0006
ÂÂÂÂÂÂÂ Button.0007
ÂÂÂÂÂÂÂ Button.0008
ÂÂÂÂÂÂÂ Button.0009
ÂÂÂÂÂÂÂ Button.000a
ÂÂÂÂÂÂÂ Button.000b
ÂÂÂÂÂÂÂ Button.000c
ÂÂÂÂÂÂÂ Button.000d
ÂÂÂÂÂÂÂ Button.000e
ÂÂÂÂÂÂÂ Button.000f
ÂÂÂÂÂÂÂ Button.0010
ÂÂÂÂÂ Logical Minimum(0)
ÂÂÂÂÂ Logical Maximum(255)
ÂÂÂÂÂ Report Size(8)
ÂÂÂÂÂ Report Count(16)
ÂÂÂÂÂ Report Offset(0)
ÂÂÂÂÂ Flags( Variable Absolute )
 INPUT(160)[INPUT]
ÂÂÂ Field(0)
ÂÂÂÂÂ Application(Consumer.0001)
ÂÂÂÂÂ Usage(16)
ÂÂÂÂÂÂÂ Button.ff00
ÂÂÂÂÂÂÂ Button.ff00
ÂÂÂÂÂÂÂ Button.ff00
ÂÂÂÂÂÂÂ Button.ff00

>>> Is it broken in Linus's tree?  If so, can you work with the HID
>>> developers to fix it there so we can backport the fix to all stable
>>> trees?
>> I cant see that there are any other fixes upon this so I dont think so. 
>> I can try.
>>
>>
>> Jiri is in the loop. I guess he is the "HID developers" ?
> Thanks,
>