linux-kernel - Re: [PATCH 2/3] HID: steam: add serial number information.

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: <20180220174540.GA8231@casa>
Date:   Tue, 20 Feb 2018 18:45:40 +0100
From:   Rodrigo Rivas Costa <rodrigorivascosta@...il.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>, linux-input@...r.kernel.org
Subject: Re: [PATCH 2/3] HID: steam: add serial number information.

On Tue, Feb 20, 2018 at 05:49:02PM +0100, Benjamin Tissoires wrote:
> On Fri, Feb 16, 2018 at 9:59 PM, Rodrigo Rivas Costa
> > But about that +7 in hid_alloc_report_buf(), isn't it to make room for
> > the implement()/extract() functions? And IIUIC those are not used for
> > raw_requests... they are instead passed directly to usb_control_msg()
> > (or whatever the ll driver does). That's the point of being raw, isn't
> > it?
> >
> > If I'm right with that, would it make sense to go back to kzalloc(65)?
> >
> > If I'm wrong, then if you agree, I'll default to:
> >
> >         hid_hw_raw_request(steam->hid_dev, 0x00,
> >                 buf, hid_report_len(r) + 1, /* count the request number */
> >                 HID_FEATURE_REPORT, HID_REQ_GET_REPORT);
> >
> > Then, if hid_report_len() is ever updated to return the +1, this one
> > should be removed. And even if it is not, we still have +6 extra bytes
> > from hid_alloc_report_buf(), so no real harm done.
> 
> I am fine with your analysis except for the last point :)
> We need all 7 extra bytes, not 6 (in implement()). However, as you
> said, implement() is not used in the low_level transport functions, so
> there is no point bike shedding for ages.
> 
> I'd say please stick to hid_report_alloc_buf (maybe add a comment
> about the missing report ID added by usb), and use hid_report_len(r) +
> 1 while calling hid_hw_raw_request(). This way, we can always fix the
> behavior later and have something which will not break.
> 
> How does that sound?
It sound fine to me. I'll try to write a small comment explaining the
+1.

Thanks
Rodrigo