linux-kernel - Re: [PATCH v2] HID: core: Sanitize event code and type when mapping input

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 27 Aug 2020 22:01:21 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] HID: core: Sanitize event code and type when mapping
 input

On 2020-08-27 10:33, Jiri Kosina wrote:
> On Wed, 26 Aug 2020, Marc Zyngier wrote:
> 
>> When calling into hid_map_usage(), the passed event code is
>> blindly stored as is, even if it doesn't fit in the associated bitmap.
>> 
>> This event code can come from a variety of sources, including devices
>> masquerading as input devices, only a bit more "programmable".
>> 
>> Instead of taking the event code at face value, check that it actually
>> fits the corresponding bitmap, and if it doesn't:
>> - spit out a warning so that we know which device is acting up
>> - NULLify the bitmap pointer so that we catch unexpected uses
>> 
>> Code paths that can make use of untrusted inputs can now check
>> that the mapping was indeed correct and bail out if not.
>> 
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Marc Zyngier <maz@...nel.org>
>> ---
>> * From v1:
>>   - Dropped the input.c changes, and turned hid_map_usage() into
>>     the validation primitive.
>>   - Handle mapping failures in hidinput_configure_usage() and
>>     mt_touch_input_mapping() (on top of hid_map_usage_clear() which
>>     was already handled)
> 
> Benjamin, could you please run this through your regression testing
> machinery?
> 
> It's a non-trivial core change, at the same time I'd like not to 
> postpone
> it for 5.10 due to its nature.

I found yet another nit that this patch doesn't quite catch.
v3 going out in a minute.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...