[<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