<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/hid/uhid.c, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-01-27T07:47:31Z</updated>
<entry>
<title>HID: uhid: Fix worker destroying device without any protection</title>
<updated>2022-01-27T07:47:31Z</updated>
<author>
<name>Jann Horn</name>
</author>
<published>2022-01-14T13:33:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=97da015fe8206e195324127ba10a8d67d22d06ba'/>
<id>urn:sha1:97da015fe8206e195324127ba10a8d67d22d06ba</id>
<content type='text'>
commit 4ea5763fb79ed89b3bdad455ebf3f33416a81624 upstream.

uhid has to run hid_add_device() from workqueue context while allowing
parallel use of the userspace API (which is protected with -&gt;devlock).
But hid_add_device() can fail. Currently, that is handled by immediately
destroying the associated HID device, without using -&gt;devlock - but if
there are concurrent requests from userspace, that's wrong and leads to
NULL dereferences and/or memory corruption (via use-after-free).

Fix it by leaving the HID device as-is in the worker. We can clean it up
later, either in the UHID_DESTROY command handler or in the -&gt;release()
handler.

Cc: stable@vger.kernel.org
Fixes: 67f8ecc550b5 ("HID: uhid: fix timeout when probe races with IO")
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: introduce hid_is_using_ll_driver</title>
<updated>2021-12-14T09:04:46Z</updated>
<author>
<name>Jason Gerecke</name>
</author>
<published>2017-07-24T16:46:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e1e84bd83f1d2eb4d37ad1b62aa67c29665e1184'/>
<id>urn:sha1:e1e84bd83f1d2eb4d37ad1b62aa67c29665e1184</id>
<content type='text'>
commit fc2237a724a9e448599076d7d23497f51e2f7441 upstream.

Although HID itself is transport-agnostic, occasionally a driver may
want to interact with the low-level transport that a device is connected
through. To do this, we need to know what kind of bus is in use. The
first guess may be to look at the 'bus' field of the 'struct hid_device',
but this field may be emulated in some cases (e.g. uhid).

More ideally, we can check which ll_driver a device is using. This
function introduces a 'hid_is_using_ll_driver' function and makes the
'struct hid_ll_driver' of the four most common transports accessible
through hid.h.

Signed-off-by: Jason Gerecke &lt;jason.gerecke@wacom.com&gt;
Acked-By: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: hidraw, uhid: Always report EPOLLOUT</title>
<updated>2020-01-23T07:19:33Z</updated>
<author>
<name>Jiri Kosina</name>
</author>
<published>2020-01-10T14:32:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f6d018785dbcf8032418d3242028bf42a34846bf'/>
<id>urn:sha1:f6d018785dbcf8032418d3242028bf42a34846bf</id>
<content type='text'>
[ Upstream commit 9e635c2851df6caee651e589fbf937b637973c91 ]

hidraw and uhid device nodes are always available for writing so we should
always report EPOLLOUT and EPOLLWRNORM bits, not only in the cases when
there is nothing to read.

Reported-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Fixes: be54e7461ffdc ("HID: uhid: Fix returning EPOLLOUT from uhid_char_poll")
Fixes: 9f3b61dc1dd7b ("HID: hidraw: Fix returning EPOLLOUT from hidraw_poll")
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: uhid: Fix returning EPOLLOUT from uhid_char_poll</title>
<updated>2020-01-14T19:04:27Z</updated>
<author>
<name>Marcel Holtmann</name>
</author>
<published>2019-12-04T02:43:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4d29a64055970a204c8bef0c2b299c22e7e73617'/>
<id>urn:sha1:4d29a64055970a204c8bef0c2b299c22e7e73617</id>
<content type='text'>
commit be54e7461ffdc5809b67d2aeefc1ddc9a91470c7 upstream.

Always return EPOLLOUT from uhid_char_poll to allow polling /dev/uhid
for writable state.

Fixes: 1f9dec1e0164 ("HID: uhid: allow poll()'ing on uhid devices")
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>HID: uhid: forbid UHID_CREATE under KERNEL_DS or elevated privileges</title>
<updated>2018-11-27T15:09:42Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2018-11-14T21:55:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ab26f7fd578afad4eec4b4282fb6324f1940f50d'/>
<id>urn:sha1:ab26f7fd578afad4eec4b4282fb6324f1940f50d</id>
<content type='text'>
commit 8c01db7619f07c85c5cd81ec5eb83608b56c88f5 upstream.

When a UHID_CREATE command is written to the uhid char device, a
copy_from_user() is done from a user pointer embedded in the command.
When the address limit is KERNEL_DS, e.g. as is the case during
sys_sendfile(), this can read from kernel memory.  Alternatively,
information can be leaked from a setuid binary that is tricked to write
to the file descriptor.  Therefore, forbid UHID_CREATE in these cases.

No other commands in uhid_char_write() are affected by this bug and
UHID_CREATE is marked as "obsolete", so apply the restriction to
UHID_CREATE only rather than to uhid_char_write() entirely.

Thanks to Dmitry Vyukov for adding uhid definitions to syzkaller and to
Jann Horn for commit 9da3f2b740544 ("x86/fault: BUG() when uaccess
helpers fault on kernel addresses"), allowing this bug to be found.

Reported-by: syzbot+72473edc9bf4eb1c6556@syzkaller.appspotmail.com
Fixes: d365c6cfd337 ("HID: uhid: add UHID_CREATE and UHID_DESTROY events")
Cc: &lt;stable@vger.kernel.org&gt; # v3.6+
Cc: Jann Horn &lt;jannh@google.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Jann Horn &lt;jannh@google.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>miscdevice: Add helper macro for misc device boilerplate</title>
<updated>2016-08-31T12:12:35Z</updated>
<author>
<name>PrasannaKumar Muralidharan</name>
</author>
<published>2016-08-25T17:00:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca75d601b5942e8cf5eed68f308be0526d0dac5d'/>
<id>urn:sha1:ca75d601b5942e8cf5eed68f308be0526d0dac5d</id>
<content type='text'>
Many modules call misc_register and misc_deregister in its module init
and exit methods without any additional code. This ends up being
boilerplate. This patch adds helper macro module_misc_device(), that
replaces module_init()/ module_exit() with template functions.

This patch also converts drivers to use new macro.

Change since v1:
Add device.h include in miscdevice.h as module_driver macro was not
available from other include files in some architectures.

Signed-off-by: PrasannaKumar Muralidharan &lt;prasannatsmkumar@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: uhid: fix timeout when probe races with IO</title>
<updated>2016-06-01T14:24:54Z</updated>
<author>
<name>Roderick Colenbrander</name>
</author>
<published>2016-05-18T20:11:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=67f8ecc550b5bda03335f845dc869b8501d25fd0'/>
<id>urn:sha1:67f8ecc550b5bda03335f845dc869b8501d25fd0</id>
<content type='text'>
Many devices use userspace bluetooth stacks like BlueZ or Bluedroid in combination
with uhid. If any of these stacks is used with a HID device for which the driver
performs a HID request as part .probe (or technically another HID operation),
this results in a deadlock situation. The deadlock results in a 5 second timeout
for I/O operations in HID drivers, so isn't fatal, but none of the I/O operations
have a chance of succeeding.

The root cause for the problem is that uhid only allows for one request to be
processed at a time per uhid instance and locks out other operations. This means
that if a user space is creating a new HID device through 'UHID_CREATE', which
ultimately triggers '.probe' through the HID layer. Then any HID request e.g. a
read for calibration data would trigger a HID operation on uhid again, but it
won't go out to userspace, because it is still stuck in UHID_CREATE.
In addition bluetooth stacks are typically single threaded, so they wouldn't be
able to handle any requests while waiting on uhid.

Lucikly the UHID spec is somewhat flexible and allows for fixing the issue,
without breaking user space. The idea which the patch implements as discussed
with David Herrmann is to decouple adding of a hid device (which triggers .probe)
from UHID_CREATE. The work will kick off roughly once UHID_CREATE completed (or
else will wait a tiny bit of time in .probe for a lock). A HID driver has to call
HID to call 'hid_hw_start()' as part of .probe once it is ready for I/O, which
triggers UHID_START to user space. Any HID operations should function now within
.probe and won't deadlock because userspace is stuck on UHID_CREATE.

We verified this patch on Bluedroid with Android 6.0 and on desktop Linux with
BlueZ stacks. Prior to the patch they had the deadlock issue.

[jkosina@suse.cz: reword subject]
Signed-off-by: Roderick Colenbrander &lt;roderick.colenbrander@sony.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>drivers/hid/uhid.c: check write() bitness using in_compat_syscall</title>
<updated>2016-03-22T22:36:02Z</updated>
<author>
<name>Andy Lutomirski</name>
</author>
<published>2016-03-22T21:25:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7365abbade07f9181cbd013669642f129e9ec635'/>
<id>urn:sha1:7365abbade07f9181cbd013669642f129e9ec635</id>
<content type='text'>
uhid changes the format expected in write() depending on bitness.  It
should check the syscall bitness directly.

Signed-off-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: David Herrmann &lt;dh.herrmann@googlemail.com&gt;
Acked-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>HID: uHID: fix excepted report type</title>
<updated>2014-10-01T18:58:46Z</updated>
<author>
<name>Benjamin Tissoires</name>
</author>
<published>2014-10-01T15:59:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8493ecca74a7b4a66e19676de1a0f14194179941'/>
<id>urn:sha1:8493ecca74a7b4a66e19676de1a0f14194179941</id>
<content type='text'>
When uhid_get_report() or uhid_set_report() are called, they emit on the
char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
or UHID_SET_REPORT_REPLY.

Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
or UHID_SET_REPORT instead of the reply one.
Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
reply, and validate the reply.

Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Reviewed-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
<entry>
<title>HID: uhid: report to user-space whether reports are numbered</title>
<updated>2014-08-25T08:28:08Z</updated>
<author>
<name>David Herrmann</name>
</author>
<published>2014-07-29T15:14:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c2b2f16c5c62583d4f8904e44c4b30c94a01eaf1'/>
<id>urn:sha1:c2b2f16c5c62583d4f8904e44c4b30c94a01eaf1</id>
<content type='text'>
This makes UHID_START include a "dev_flags" field that describes details
of the hid-device in the kernel. The first flags we introduce describe
whether a given report-type uses numbered reports. This is useful for
transport layers that force report-numbers and therefore might have to
prefix kernel-provided HID-messages with the report-number.

Currently, only HoG needs this and the spec only talks about "global
report numbers". That is, it's a global boolean not a per-type boolean.
However, given the quirks we already have in kernel-space, a per-type
value seems much more appropriate.

Signed-off-by: David Herrmann &lt;dh.herrmann@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
</feed>
