<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/hid, branch v6.19.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-11T12:29:56+00:00</updated>
<entry>
<title>HID: appletb-kbd: add .resume method in PM</title>
<updated>2026-04-11T12:29:56+00:00</updated>
<author>
<name>Aditya Garg</name>
<email>gargaditya08@live.com</email>
</author>
<published>2026-04-07T11:08:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=854c6b49c2920139eecebc7245cca53d207a7b0d'/>
<id>urn:sha1:854c6b49c2920139eecebc7245cca53d207a7b0d</id>
<content type='text'>
commit 1965445e13c09b79932ca8154977b4408cb9610c upstream.

Upon resuming from suspend, the Touch Bar driver was missing a resume
method in order to restore the original mode the Touch Bar was on before
suspending. It is the same as the reset_resume method.

Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg &lt;gargaditya08@live.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: multitouch: Check to ensure report responses match the request</title>
<updated>2026-04-11T12:29:21+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2026-02-27T16:30:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2edc92f89eee328b5be5706b5d431bf90669e9c0'/>
<id>urn:sha1:2edc92f89eee328b5be5706b5d431bf90669e9c0</id>
<content type='text'>
[ Upstream commit e716edafedad4952fe3a4a273d2e039a84e8681a ]

It is possible for a malicious (or clumsy) device to respond to a
specific report's feature request using a completely different report
ID.  This can cause confusion in the HID core resulting in nasty
side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the
one that was requested.  If it doesn't, omit reporting the raw event and
return early.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: core: Mitigate potential OOB by removing bogus memset()</title>
<updated>2026-04-11T12:29:21+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2026-03-09T14:59:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bd6e1d0230cca9575f5d118148f51e2a56b5373f'/>
<id>urn:sha1:bd6e1d0230cca9575f5d118148f51e2a56b5373f</id>
<content type='text'>
[ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]

The memset() in hid_report_raw_event() has the good intention of
clearing out bogus data by zeroing the area from the end of the incoming
data string to the assumed end of the buffer.  However, as we have
previously seen, doing so can easily result in OOB reads and writes in
the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the
memset() and simply return if the incoming event buffer size is not
large enough to fill the associated report.

Suggested-by Benjamin Tissoires &lt;bentiss@kernel.org&gt;

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
[bentiss: changed the return value]
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure</title>
<updated>2026-04-11T12:29:21+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2026-02-27T10:09:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a793ac19eb84f44ed759c0fce80cf29bc2a2453'/>
<id>urn:sha1:9a793ac19eb84f44ed759c0fce80cf29bc2a2453</id>
<content type='text'>
[ Upstream commit f7a4c78bfeb320299c1b641500fe7761eadbd101 ]

Presently, if the force feedback initialisation fails when probing the
Logitech G920 Driving Force Racing Wheel for Xbox One, an error number
will be returned and propagated before the userspace infrastructure
(sysfs and /dev/input) has been torn down.  If userspace ignores the
errors and continues to use its references to these dangling entities, a
UAF will promptly follow.

We have 2 options; continue to return the error, but ensure that all of
the infrastructure is torn down accordingly or continue to treat this
condition as a warning by emitting the message but returning success.
It is thought that the original author's intention was to emit the
warning but keep the device functional, less the force feedback feature,
so let's go with that.

Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
Reviewed-by: Günther Noack &lt;gnoack@google.com&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq</title>
<updated>2026-04-11T12:29:20+00:00</updated>
<author>
<name>Benoît Sevens</name>
<email>bsevens@google.com</email>
</author>
<published>2026-03-03T13:58:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3d78386b144453c47e81bf62dc3601b757f02d99'/>
<id>urn:sha1:3d78386b144453c47e81bf62dc3601b757f02d99</id>
<content type='text'>
[ Upstream commit 2f1763f62909ccb6386ac50350fa0abbf5bb16a9 ]

The wacom_intuos_bt_irq() function processes Bluetooth HID reports
without sufficient bounds checking. A maliciously crafted short report
can trigger an out-of-bounds read when copying data into the wacom
structure.

Specifically, report 0x03 requires at least 22 bytes to safely read
the processed data and battery status, while report 0x04 (which
falls through to 0x03) requires 32 bytes.

Add explicit length checks for these report IDs and log a warning if
a short report is received.

Signed-off-by: Benoît Sevens &lt;bsevens@google.com&gt;
Reviewed-by: Jason Gerecke &lt;jason.gerecke@wacom.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: logitech-hidpp: Enable MX Master 4 over bluetooth</title>
<updated>2026-04-11T12:29:20+00:00</updated>
<author>
<name>Adrian Freund</name>
<email>adrian@freund.io</email>
</author>
<published>2026-03-11T19:19:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=29f9758749d38075917a685263ba84df566338fc'/>
<id>urn:sha1:29f9758749d38075917a685263ba84df566338fc</id>
<content type='text'>
[ Upstream commit 70031e70ca15ede6a39db4d978e53a6cc720d454 ]

The Logitech MX Master 4 can be connected over bluetooth or through a
Logitech Bolt receiver. This change adds support for non-standard HID
features, such as high resolution scrolling when the mouse is connected
over bluetooth.
Because no Logitech Bolt receiver driver exists yet those features
won't be available when the mouse is connected through the receiver.

Signed-off-by: Adrian Freund &lt;adrian@freund.io&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: apple: avoid memory leak in apple_report_fixup()</title>
<updated>2026-04-02T11:25:20+00:00</updated>
<author>
<name>Günther Noack</name>
<email>gnoack@google.com</email>
</author>
<published>2026-02-19T15:43:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e652ebd29928181c3e6820e303da25873e9917d4'/>
<id>urn:sha1:e652ebd29928181c3e6820e303da25873e9917d4</id>
<content type='text'>
[ Upstream commit 239c15116d80f67d32f00acc34575f1a6b699613 ]

The apple_report_fixup() function was returning a
newly kmemdup()-allocated buffer, but never freeing it.

The caller of report_fixup() does not take ownership of the returned
pointer, but it *is* permitted to return a sub-portion of the input
rdesc, whose lifetime is managed by the caller.

Assisted-by: Gemini-CLI:Google Gemini 3
Signed-off-by: Günther Noack &lt;gnoack@google.com&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: asus: add xg mobile 2023 external hardware support</title>
<updated>2026-04-02T11:25:18+00:00</updated>
<author>
<name>Denis Benato</name>
<email>denis.benato@linux.dev</email>
</author>
<published>2026-02-16T17:55:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b34e24936615b515603a19a15a9df2d07e68ea0e'/>
<id>urn:sha1:b34e24936615b515603a19a15a9df2d07e68ea0e</id>
<content type='text'>
[ Upstream commit 377f8e788945d45b012ed9cfc35ca56c02e86cd8 ]

XG mobile stations have the 0x5a endpoint and has to be initialized:
add them to hid-asus.

Signed-off-by: Denis Benato &lt;denis.benato@linux.dev&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: mcp2221: cancel last I2C command on read error</title>
<updated>2026-04-02T11:25:18+00:00</updated>
<author>
<name>Romain Sioen</name>
<email>romain.sioen@microchip.com</email>
</author>
<published>2026-02-06T16:32:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54a7cf41e47684505f07c25bce93d5b6d535d43b'/>
<id>urn:sha1:54a7cf41e47684505f07c25bce93d5b6d535d43b</id>
<content type='text'>
[ Upstream commit e31b556c0ba21f20c298aa61181b96541140b7b9 ]

When an I2C SMBus read operation fails, the MCP2221 internal state machine
may not reset correctly, causing subsequent transactions to fail.

By adding a short delay and explicitly cancelling the last command,
we ensure the device is ready for the next operation.

Fix an issue where i2cdetect was not able to detect all devices correctly
on the bus.

Signed-off-by: Romain Sioen &lt;romain.sioen@microchip.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: apple: Add EPOMAKER TH87 to the non-apple keyboards list</title>
<updated>2026-04-02T11:25:17+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2026-02-24T09:00:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e14511eab84873e111842a0c3ad4806e1e22407c'/>
<id>urn:sha1:e14511eab84873e111842a0c3ad4806e1e22407c</id>
<content type='text'>
[ Upstream commit 7c698de0dc5daa1e1a5fd1f0c6aa1b6bb2f5d867 ]

EPOMAKER TH87 has the very same ID as Apple Aluminum keyboard
(05ac:024f) although it doesn't work as expected in compatible way.

Put three entries to the non-apple keyboards list to exclude this
device: one for BT ("TH87"), one for USB ("HFD Epomaker TH87") and one
for dongle ("2.4G Wireless Receiver").

Link: https://bugzilla.suse.com/show_bug.cgi?id=1258455
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
