Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1517709ybp; Fri, 11 Oct 2019 15:49:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqw6i8fKjH4rgEPzakFh0hNmKjmDS+I9pc/FW2LlP1AdZjtOF/d40z6gl73VWOGNor/JjXk+ X-Received: by 2002:aa7:cfd4:: with SMTP id r20mr15864904edy.268.1570834184966; Fri, 11 Oct 2019 15:49:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570834184; cv=none; d=google.com; s=arc-20160816; b=lCGjVBEhEhcBsBHB9HwRAYV1DBRFA9tfwxkDamccXpUY88+tzKysoM6f5AJFGQCJuW yscE6+dByRGcDN6LO+SIhhBG9Lksy2zDKwYBGHyIhuEgyVDInt9J4BQoeOs1v5e7Qhh2 75ClVJKhb0oMlqNorjdNtJQ27zdX4QLHgwRXEo0tVrSGBz8kVFF9YAN9e2v8A9qmn7ks +tEC5C9O7/oiYVZhKZtwV7/m7UpCXrrLkkzb3KxkjNy0u2dv6wjCyxQHVFxcnQCYh8uy HSRYQhYjr2rqQq/JARmaYbz1vAgDtwuL2N8bdcLu2LImwO5AakhMnAm80uUlGq6OfbLL Hg7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ih6shK72SsYbUilowKrJkHCxbMKYtWGrrGp+ltqWoGg=; b=boS9WUvzgOxPAuOPFKEn+ahVFV8AogALlStj9fKdBZg/N9F6ofvqcNSFcTT5hK8Rvz Z+SRFIU4BdD9PUZ4OjCXMJX0ktKZ4os1c9zYQ2YNwXse5S5Pc69vgUCJoliAy+eCVzhK DlN4YVjFowPGHWxnyKpA5HFwU3VLilqqebzvtwfBeIdmLMe3Wn1hnnqnr0EvAHj8WFbh CgEtL6bIsueCbx1RFlI/mMei55fjb2ZbfG29Dm/p5wMoIhAtTufNe2ww9S17Nvg0vhmw 2edfP/M0aBFFdL0IT/euBoBmFwsMPzyoYEV2uh579UkWK0c1WgDNwBMxKe7a8Y+bivwv jCFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LOJbWzmn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oq3si6302329ejb.220.2019.10.11.15.49.20; Fri, 11 Oct 2019 15:49:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LOJbWzmn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727184AbfJKWdN (ORCPT + 99 others); Fri, 11 Oct 2019 18:33:13 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:59750 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726174AbfJKWdN (ORCPT ); Fri, 11 Oct 2019 18:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1570833191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ih6shK72SsYbUilowKrJkHCxbMKYtWGrrGp+ltqWoGg=; b=LOJbWzmn8ME1Apx+RM7LcoyeVKgHD+O4KBn1x2uq/dCwdXC8vhdjgd9Lsmu8/QPQwxfpjf sdrOBt1ekCDbvMyVzLw4TU6/lTBIeaHh0hawQU0Ob25XuaLn8mxIMcyIhkAWQ9VXOI7ME1 dX0VLUqAuiAXOchPcwN/P9iIsNix2fs= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-167-IqHqRbwVPGy5RUZ4TqAz-A-1; Fri, 11 Oct 2019 18:33:09 -0400 Received: by mail-qt1-f199.google.com with SMTP id h10so10934487qtq.11 for ; Fri, 11 Oct 2019 15:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xUGJx7tOM8vQwvIOh3cm4givSxEOOhsnPOf5V8GuBe4=; b=ADEMmPsA6y8ja3GA912EomSbnTyocNLIEJunRDztH9X/u+hQ68oyi5w+pF5kAPinW6 4sxy61EAVxIiusL7ipMdX7o9tzYBarNpi4QsLQzgopY/b1LFuYgM6nDamnEd48ONkHSG PFiqi5qX7DIYkMQWzE1kH094aJERO9RuMYf6ylV7zw0FtV/uXgX878556DJQCWUa3AAP JIYrwFtKIk5paKb7PZCFQub+uxQCutY5LXjoPJf8bXqLsEiM6SgkEjqEo7tSMyG0+L6a tZL/45I7tl/JD3cB+3SQSWJLrwHUOo3LN+MZ6m4kIL2KpHpQpJmPY+Z55AXsuLcsJ20m 4UeQ== X-Gm-Message-State: APjAAAXn4A7sD5tfO33epJo2qvIuY2EMJCpjIEkjutJ2iyp5BIvtIk1w 5h9w1wCBtBB1sQwPzo0PpENtCdyQbA7peWjkIass028axUt/a4fvQ9IacgdV/C9GcM6IRhnnSc0 ATJ/uuEW/R9GGe0W1fTKz1mErlzMqwR9qDk1Wps7W X-Received: by 2002:a05:620a:13d9:: with SMTP id g25mr18351866qkl.230.1570833189358; Fri, 11 Oct 2019 15:33:09 -0700 (PDT) X-Received: by 2002:a05:620a:13d9:: with SMTP id g25mr18351832qkl.230.1570833189064; Fri, 11 Oct 2019 15:33:09 -0700 (PDT) MIME-Version: 1.0 References: <20191007051240.4410-1-andrew.smirnov@gmail.com> <20191007051240.4410-4-andrew.smirnov@gmail.com> In-Reply-To: From: Benjamin Tissoires Date: Sat, 12 Oct 2019 00:32:57 +0200 Message-ID: Subject: Re: [PATCH 3/3] HID: logitech-hidpp: add G920 device validation quirk To: Andrey Smirnov Cc: "open list:HID CORE LAYER" , Sam Bazely , Jiri Kosina , Henrik Rydberg , "Pierre-Loup A . Griffais" , Austin Palmer , lkml , "3.8+" X-MC-Unique: IqHqRbwVPGy5RUZ4TqAz-A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 11, 2019 at 9:39 PM Andrey Smirnov w= rote: > > On Fri, Oct 11, 2019 at 7:56 AM Benjamin Tissoires > wrote: > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov wrote: > > > > > > G920 device only advertises REPORT_ID_HIDPP_LONG and > > > REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying > > > for REPORT_ID_HIDPP_SHORT with optional=3Dfalse will always fail and > > > prevent G920 to be recognized as a valid HID++ device. > > > > > > Modify hidpp_validate_device() to check only REPORT_ID_HIDPP_LONG wit= h > > > optional=3Dfalse on G920 to fix this. > > > > > > Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to= be handled by this module") > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=3D204191 > > > Reported-by: Sam Bazely > > > Signed-off-by: Andrey Smirnov > > > Cc: Jiri Kosina > > > Cc: Benjamin Tissoires > > > Cc: Henrik Rydberg > > > Cc: Sam Bazely > > > Cc: Pierre-Loup A. Griffais > > > Cc: Austin Palmer > > > Cc: linux-input@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Cc: stable@vger.kernel.org > > > --- > > > drivers/hid/hid-logitech-hidpp.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logit= ech-hidpp.c > > > index cadf36d6c6f3..f415bf398e17 100644 > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > @@ -3511,6 +3511,12 @@ static bool hidpp_validate_report(struct hid_d= evice *hdev, int id, > > > > > > static bool hidpp_validate_device(struct hid_device *hdev) > > > { > > > + struct hidpp_device *hidpp =3D hid_get_drvdata(hdev); > > > + > > > + if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920) > > > + return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LO= NG, > > > + HIDPP_REPORT_SHORT_LENGT= H, false); > > > + > > > > with https://patchwork.kernel.org/patch/11184749/ we also have a need > > for such a trick for BLE mice. > > > > I wonder if we should not have a more common way of validating the devi= ces > > > > What about just checking for: > > hidpp_validate_report(REPORT_ID_HIDPP_SHORT, > HIDPP_REPORT_SHORT_LENGTH, true) || > hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG, > HIDPP_REPORT_LONG_LENGTH, true); > > and probably dropping the "optional" argument for > hidpp_validate_report()? Original code allows there to be devices > supporting shorts reports only, but it seems that devices that support > only long reports are legitimate too, so maybe the only "invalid" > combination is if both are invalid length or missing? Well, the problem is we also want to detect 2 things: - devices that do not have any of the HID++ collections, and handle them as generic ones (the second mouse/keyboard collection in the gaming mice should still be exported by the driver, or this will kill the macros / rebinding capabilities - malicious devices that pretends to have a HID++ collection but want to trigger a buffer overflow by having a shorter than expected report length Point 2 above should still be fine, but point 1 is why we have the enforcement of the HID++ short report in the first place. Cheers, Benjamin > > Thanks, > Andrey Smirnov