linux-stable.git/drivers/hid, branch v5.15.78

HID: saitek: add madcatz variant of MMO7 mouse device ID

2022-11-10T17:15:34+00:00

[ Upstream commit 79425b297f56bd481c6e97700a9a4e44c7bcfa35 ]

The MadCatz variant of the MMO7 mouse has the ID 0738:1713 and the same
quirks as the Saitek variant.

Signed-off-by: Samuel Bailey 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: playstation: add initial DualSense Edge controller support

2022-11-10T17:15:25+00:00

[ Upstream commit b8a968efab301743fd659b5649c5d7d3e30e63a6 ]

Provide initial support for the DualSense Edge controller. The brings
support up to the level of the original DualSense, but won't yet provide
support for new features (e.g. reprogrammable buttons).

Signed-off-by: Roderick Colenbrander 
CC: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires 
Link: https://lore.kernel.org/r/20221010212313.78275-3-roderick.colenbrander@sony.com
Signed-off-by: Sasha Levin

HID: magicmouse: Do not set BTN_MOUSE on double report

2022-10-29T08:12:55+00:00

[ Upstream commit bb5f0c855dcfc893ae5ed90e4c646bde9e4498bf ]

Under certain conditions the Magic Trackpad can group 2 reports in a
single packet. The packet is split and the raw event function is
invoked recursively for each part.

However, after processing each part, the BTN_MOUSE status is updated,
sending multiple click events. [1]

Return after processing double reports to avoid this issue.

Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/811  # [1]
Fixes: a462230e16ac ("HID: magicmouse: enable Magic Trackpad support")
Reported-by: Nulo 
Signed-off-by: José Expósito 
Signed-off-by: Benjamin Tissoires 
Link: https://lore.kernel.org/r/20221009182747.90730-1-jose.exposito89@gmail.com
Signed-off-by: Sasha Levin

HID: roccat: Fix use-after-free in roccat_read()

2022-10-26T10:35:48+00:00

[ Upstream commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 ]

roccat_report_event() is responsible for registering
roccat-related reports in struct roccat_device.

int roccat_report_event(int minor, u8 const *data)
{
	struct roccat_device *device;
	struct roccat_reader *reader;
	struct roccat_report *report;
	uint8_t *new_value;

	device = devices[minor];

	new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
	if (!new_value)
		return -ENOMEM;

	report = &device->cbuf[device->cbuf_end];

	/* passing NULL is safe */
	kfree(report->value);
	...

The registered report is stored in the struct roccat_device member
"struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
If more reports are received than the "ROCCAT_CBUF_SIZE" value,
kfree() the saved report from cbuf[0] and allocates a new reprot.
Since there is no lock when this kfree() is performed,
kfree() can be performed even while reading the saved report.

static ssize_t roccat_read(struct file *file, char __user *buffer,
		size_t count, loff_t *ppos)
{
	struct roccat_reader *reader = file->private_data;
	struct roccat_device *device = reader->device;
	struct roccat_report *report;
	ssize_t retval = 0, len;
	DECLARE_WAITQUEUE(wait, current);

	mutex_lock(&device->cbuf_lock);

	...

	report = &device->cbuf[reader->cbuf_start];
	/*
	 * If report is larger than requested amount of data, rest of report
	 * is lost!
	 */
	len = device->report_size > count ? count : device->report_size;

	if (copy_to_user(buffer, report->value, len)) {
		retval = -EFAULT;
		goto exit_unlock;
	}
	...

The roccat_read() function receives the device->cbuf report and
delivers it to the user through copy_to_user().
If the N+ROCCAT_CBUF_SIZE th report is received while copying of
the Nth report->value is in progress, the pointer that copy_to_user()
is working on is kfree()ed and UAF read may occur. (race condition)

Since the device node of this driver does not set separate permissions,
this is not a security vulnerability, but because it is used for
requesting screen display of profile or dpi settings,
a user using the roccat device can apply udev to this device node or
There is a possibility to use it by giving.

Signed-off-by: Hyunwoo Kim 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: multitouch: Add memory barriers

2022-10-26T10:34:21+00:00

commit be6e2b5734a425941fcdcdbd2a9337be498ce2cf upstream.

This fixes broken atomic checks which cause a race between the
release-timer and processing of hid input.

I noticed that contacts were sometimes sticking, even with the "sticky
fingers" quirk enabled. This fixes that problem.

Cc: stable@vger.kernel.org
Fixes: 9609827458c3 ("HID: multitouch: optimize the sticky fingers timer")
Signed-off-by: Andri Yngvason 
Signed-off-by: Benjamin Tissoires 
Link: https://lore.kernel.org/r/20220907150159.2285460-1-andri@yngvason.is
Signed-off-by: Greg Kroah-Hartman

hid: intel-ish-hid: ishtp: Fix ishtp client sending disordered message

2022-09-20T10:39:44+00:00

[ Upstream commit e1fa076706209cc447d7a2abd0843a18277e5ef7 ]

There is a timing issue captured during ishtp client sending stress tests.
It was observed during stress tests that ISH firmware is getting out of
ordered messages. This is a rare scenario as the current set of ISH client
drivers don't send much data to firmware. But this may not be the case
going forward.

When message size is bigger than IPC MTU, ishtp splits the message into
fragments and uses serialized async method to send message fragments.
The call stack:
ishtp_cl_send_msg_ipc->ipc_tx_callback(first fregment)->
ishtp_send_msg(with callback)->write_ipc_to_queue->
write_ipc_from_queue->callback->ipc_tx_callback(next fregment)......

When an ipc write complete interrupt is received, driver also calls
write_ipc_from_queue->ipc_tx_callback in ISR to start sending of next fragment.

Through ipc_tx_callback uses spin_lock to protect message splitting, as the
serialized sending method will call back to ipc_tx_callback again, so it doesn't
put sending under spin_lock, it causes driver cannot guarantee all fragments
be sent in order.

Considering this scenario:
ipc_tx_callback just finished a fragment splitting, and not call ishtp_send_msg
yet, there is a write complete interrupt happens, then ISR->write_ipc_from_queue
->ipc_tx_callback->ishtp_send_msg->write_ipc_to_queue......

Because ISR has higher exec priority than normal thread, this causes the new
fragment be sent out before previous fragment. This disordered message causes
invalid message to firmware.

The solution is, to send fragments synchronously:
Use ishtp_write_message writing fragments into tx queue directly one by one,
instead of ishtp_send_msg only writing one fragment with completion callback.
As no completion callback be used, so change ipc_tx_callback to ipc_tx_send.

Signed-off-by: Even Xu 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo

2022-09-20T10:39:44+00:00

[ Upstream commit 94553f8a218540d676efbf3f7827ed493d1057cf ]

The double `like' is duplicated in the comment, remove one.

Signed-off-by: Jason Wang 
Signed-off-by: Jiri Kosina 
Signed-off-by: Sasha Levin

HID: thrustmaster: Add sparco wheel and fix array length

2022-09-05T08:30:08+00:00

commit d9a17651f3749e69890db57ca66e677dfee70829 upstream.

Add device id for the Sparco R383 Mod wheel.

Fix wheel info array length to match actual wheel count present in the array.

Signed-off-by: Michael Hübner 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: asus: ROG NKey: Ignore portion of 0x5a report

2022-09-05T08:30:08+00:00

commit 1c0cc9d11c665020cbeb80e660fb8929164407f4 upstream.

On an Asus G513QY, of the 5 bytes in a 0x5a report, only the first byte
is a meaningful keycode. The other bytes are zeroed out or hold garbage
from the last packet sent to the keyboard.

This patch fixes up the report descriptor for this event so that the
general hid code will only process 1 byte for keycodes, avoiding
spurious key events and unmapped Asus vendor usagepage code warnings.

Signed-off-by: Josh Kilmer 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman

HID: AMD_SFH: Add a DMI quirk entry for Chromebooks

2022-09-05T08:30:08+00:00

commit adada3f4930ac084740ea340bd8e94028eba4f22 upstream.

Google Chromebooks use Chrome OS Embedded Controller Sensor Hub instead
of Sensor Hub Fusion and leaves MP2 uninitialized, which disables all
functionalities, even including the registers necessary for feature
detections.

The behavior was observed with Lenovo ThinkPad C13 Yoga.

Signed-off-by: Akihiko Odaki 
Suggested-by: Mario Limonciello 
Acked-by: Basavaraj Natikar 
Signed-off-by: Jiri Kosina 
Signed-off-by: Greg Kroah-Hartman