linux-kernel - Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

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

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

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

Message-ID: <91cda49d4fda10781dc2add8174536cf6b91a527.camel@archlinux.org>
Date:   Wed, 10 Mar 2021 20:55:12 +0000
From:   Filipe Laíns <lains@...hlinux.org>
To:     markh@...pro.net, Jiri Kosina <jkosina@...e.cz>, sashal@...nel.org,
        Linux-kernel <linux-kernel@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>
Subject: Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+
 kernels

On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
> 
> That is correct, I don't have any buttons bound to keyboard events. With 
> the original patch the G4(forward) and G5(Backward) buttons work in a 
> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
> 
> However this patch does not seem to fix the messages I get.
> 
> Regards
> Mark

Those events belong to the USB HID button usage page and are sent by the
receiver in the HID device with the unnumbered report descriptor, so they are
not affected.

Looking at the report descriptor for the other HID device, I see a report ID of
128 (0x80) used for a vendor application, I am not really sure what it is used
for and can't seem to trigger my device to send it.

I am gonna guess this is the device reporting the pressed buttons via vendor
reports or something like that. Speaking as the person who added support for
this device in libratbag, this report is very likely not something that we don't
need in our custom drivers and just likely something extra that Logitech built
to achieve something custom in the Windows driver. FWIW, this device is a very
weird one, it does not even follow Logitech's own spec :P

Seeing this report the driver chugs.

	if (report > REPORT_TYPE_RFREPORT_LAST) {
		hid_err(hdev, "Unexpected input report number %d\n", report);
		return;
	}

Causing your

[   36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
[   36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
[   42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128

I feel like the correct fix for these cases is not to consume the report and not
forward it to device node, but rather to forward it to the receiver node.

(looping in Hans)
Hans, you introduced this code, do you remember why? Where did
REPORT_TYPE_RFREPORT_LAST get its value from and what is the purpose of this
check?
Shouldn't we just keep forwarding unknown reports to the receiver node? Is there
any technical limitation to do that? I am not too familiar with this part of the
code.

Cheers,
Filipe Laíns

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)