[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2302231156420.1142@cbobk.fhfr.pm>
Date: Thu, 23 Feb 2023 11:57:24 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Lee Jones <lee@...nel.org>
cc: benjamin.tissoires@...hat.com, linux-kernel@...r.kernel.org,
linux-input@...r.kernel.org
Subject: Re: [PATCH v2 1/2] HID: core: Provide new max_buffer_size attribute
to over-ride the default
On Mon, 23 Jan 2023, Lee Jones wrote:
> Presently, when a report is processed, its proposed size, provided by
> the user of the API (as Report Size * Report Count) is compared against
> the subsystem default HID_MAX_BUFFER_SIZE (16k). However, some
> low-level HID drivers allocate a reduced amount of memory to their
> buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
> this check inadequate in some cases.
>
> In these circumstances, if the received report ends up being smaller
> than the proposed report size, the remainder of the buffer is zeroed.
> That is, the space between sizeof(csize) (size of the current report)
> and the rsize (size proposed i.e. Report Size * Report Count), which can
> be handled up to HID_MAX_BUFFER_SIZE (16k). Meaning that memset()
> shoots straight past the end of the buffer boundary and starts zeroing
> out in-use values, often resulting in calamity.
>
> This patch introduces a new variable into 'struct hid_ll_driver' where
> individual low-level drivers can over-ride the default maximum value of
> HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
> interface.
>
> Signed-off-by: Lee Jones <lee@...nel.org>
> ---
> v1 => v2:
> - Edit the commit message to be less focused on UHID
Now applied to hid.git#for-6.3/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists