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: <nycvar.YFH.7.76.2008271132050.27422@cbobk.fhfr.pm>
Date:   Thu, 27 Aug 2020 11:33:10 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Marc Zyngier <maz@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
cc:     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 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.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ