<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/drivers/hid/hidraw.c, branch update-toolchain</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/drivers/hid/hidraw.c?h=update-toolchain</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/drivers/hid/hidraw.c?h=update-toolchain'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2024-07-01T12:48:11Z</updated>
<entry>
<title>HID: bpf: fix gcc warning and unify __u64 into u64</title>
<updated>2024-07-01T12:48:11Z</updated>
<author>
<name>Benjamin Tissoires</name>
<email>bentiss@kernel.org</email>
</author>
<published>2024-07-01T12:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=762ced1630a97a457ad2fd5f5a36849009808431'/>
<id>urn:sha1:762ced1630a97a457ad2fd5f5a36849009808431</id>
<content type='text'>
I've got multiple reports of:
error: cast from pointer to integer of different size
[-Werror=pointer-to-int-cast].

Let's use the same trick than kernel/bpf/helpers.c to shut up that warning.

Even if we were on an architecture with addresses on more than 64 bits,
this isn't much of an issue as the address is not used as a pointer,
but as an hash and the caller is not supposed to go back to the kernel
address ever.

And while we change those, make sure we use u64 instead of __u64 for
consistency

Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/
Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/
Reported-by: Mirsad Todorovac &lt;mtodorovac69@gmail.com&gt;
Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions")
Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.org
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: bpf: add HID-BPF hooks for hid_hw_output_report</title>
<updated>2024-06-27T09:00:45Z</updated>
<author>
<name>Benjamin Tissoires</name>
<email>bentiss@kernel.org</email>
</author>
<published>2024-06-26T13:46:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=9286675a2aed40a517be8cc4e283a04f473275b5'/>
<id>urn:sha1:9286675a2aed40a517be8cc4e283a04f473275b5</id>
<content type='text'>
Same story than hid_hw_raw_requests:

This allows to intercept and prevent or change the behavior of
hid_hw_output_report() from a bpf program.

The intent is to solve a couple of use case:
  - firewalling a HID device: a firewall can monitor who opens the hidraw
    nodes and then prevent or allow access to write operations on that
    hidraw node.
  - change the behavior of a device and emulate a new HID feature request

The hook is allowed to be run as sleepable so it can itself call
hid_hw_output_report(), which allows to "convert" one feature request into
another or even call the feature request on a different HID device on the
same physical device.

Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-7-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: bpf: prevent infinite recursions with hid_hw_raw_requests hooks</title>
<updated>2024-06-27T09:00:12Z</updated>
<author>
<name>Benjamin Tissoires</name>
<email>bentiss@kernel.org</email>
</author>
<published>2024-06-26T13:46:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=75839101ce52e319cb2154a027d14f1f0aa3be09'/>
<id>urn:sha1:75839101ce52e319cb2154a027d14f1f0aa3be09</id>
<content type='text'>
When we attach a sleepable hook to hid_hw_raw_requests, we can (and in
many cases should) call ourself hid_bpf_raw_request(), to actually fetch
data from the device itself.

However, this means that we might enter an infinite loop between
hid_hw_raw_requests hooks and hid_bpf_hw_request() call.

To prevent that, if a hid_bpf_hw_request() call is emitted, we prevent
any new call of this kfunc by storing the information in the context.
This way we can always trace/monitor/filter the incoming bpf requests,
while preventing those loops to happen.

I don't think exposing "from_bpf" is very interesting because while
writing such a bpf program, you need to match at least the report number
and/or the source of the call. So a blind "if there is a
hid_hw_raw_request() call, I'm emitting another one" makes no real
sense.

Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-5-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: add source argument to HID low level functions</title>
<updated>2024-06-27T08:58:19Z</updated>
<author>
<name>Benjamin Tissoires</name>
<email>bentiss@kernel.org</email>
</author>
<published>2024-06-26T13:46:23Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=67eccf151d76a9939ad8a50c6db5cb486b01df24'/>
<id>urn:sha1:67eccf151d76a9939ad8a50c6db5cb486b01df24</id>
<content type='text'>
This allows to know who actually sent what when we process the request
to the device.
This will be useful for a BPF firewall program to allow or not requests
coming from a dedicated hidraw node client.

Link: https://patch.msgid.link/20240626-hid_hw_req_bpf-v2-2-cfd60fb6c79f@kernel.org
Acked-by: Jiri Kosina &lt;jkosina@suse.com&gt;
Signed-off-by: Benjamin Tissoires &lt;bentiss@kernel.org&gt;
</content>
</entry>
<entry>
<title>HID: hidraw: fix a problem of memory leak in hidraw_release()</title>
<updated>2024-01-25T07:35:22Z</updated>
<author>
<name>Su Hui</name>
<email>suhui@nfschina.com</email>
</author>
<published>2024-01-25T06:32:26Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=a3bdcdd022c68942a774e8e63424cc11c85aab78'/>
<id>urn:sha1:a3bdcdd022c68942a774e8e63424cc11c85aab78</id>
<content type='text'>
'struct hidraw_list' is a circular queue whose head can be smaller than
tail. Using 'list-&gt;tail != list-&gt;head' to release all memory that should
be released.

Fixes: a5623a203cff ("HID: hidraw: fix memory leak in hidraw_release()")
Signed-off-by: Su Hui &lt;suhui@nfschina.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.com&gt;
</content>
</entry>
<entry>
<title>HID: hidraw: make hidraw_class structure const</title>
<updated>2023-08-05T06:31:41Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-06-20T18:31:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=32944855bac74bda81deec6c1480a82db8ef9beb'/>
<id>urn:sha1:32944855bac74bda81deec6c1480a82db8ef9beb</id>
<content type='text'>
Now that the driver core allows for struct class to be in read-only
memory, making all 'class' structures to be declared at build time
placing them into read-only memory, instead of having to be dynamically
allocated at load time.

Cc: Jiri Kosina &lt;jikos@kernel.org&gt;
Cc: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Cc: linux-input@vger.kernel.org
Cc: Ivan Orlov &lt;ivan.orlov0322@gmail.com&gt;
Link: https://lore.kernel.org/r/20230620183141.681353-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-6.5/apple' into for-linus</title>
<updated>2023-06-27T20:37:24Z</updated>
<author>
<name>Jiri Kosina</name>
<email>jkosina@suse.cz</email>
</author>
<published>2023-06-27T20:37:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=e80b500370e71b8cd7dd64be4080cee0a3e5068f'/>
<id>urn:sha1:e80b500370e71b8cd7dd64be4080cee0a3e5068f</id>
<content type='text'>
- improved support for Keychron K8 keyboard (Lasse Brun)
</content>
</entry>
<entry>
<title>HID: hidraw: fix data race on device refcount</title>
<updated>2023-06-21T15:15:48Z</updated>
<author>
<name>Ludvig Michaelsson</name>
<email>ludvig.michaelsson@yubico.com</email>
</author>
<published>2023-06-21T11:17:43Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=944ee77dc6ec7b0afd8ec70ffc418b238c92f12b'/>
<id>urn:sha1:944ee77dc6ec7b0afd8ec70ffc418b238c92f12b</id>
<content type='text'>
The hidraw_open() function increments the hidraw device reference
counter. The counter has no dedicated synchronization mechanism,
resulting in a potential data race when concurrently opening a device.

The race is a regression introduced by commit 8590222e4b02 ("HID:
hidraw: Replace hidraw device table mutex with a rwsem"). While
minors_rwsem is intended to protect the hidraw_table itself, by instead
acquiring the lock for writing, the reference counter is also protected.
This is symmetrical to hidraw_release().

Link: https://github.com/systemd/systemd/issues/27947
Fixes: 8590222e4b02 ("HID: hidraw: Replace hidraw device table mutex with a rwsem")
Cc: stable@vger.kernel.org
Signed-off-by: Ludvig Michaelsson &lt;ludvig.michaelsson@yubico.com&gt;
Link: https://lore.kernel.org/r/20230621-hidraw-race-v1-1-a58e6ac69bab@yubico.com
Signed-off-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
</content>
</entry>
<entry>
<title>driver core: class: remove module * from class_create()</title>
<updated>2023-03-17T14:16:33Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2023-03-13T18:18:35Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=1aaba11da9aa7d7d6b52a74d45b31cac118295a1'/>
<id>urn:sha1:1aaba11da9aa7d7d6b52a74d45b31cac118295a1</id>
<content type='text'>
The module pointer in class_create() never actually did anything, and it
shouldn't have been requred to be set as a parameter even if it did
something.  So just remove it and fix up all callers of the function in
the kernel tree at the same time.

Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Acked-by: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: hidraw: fix memory leak in hidraw_release()</title>
<updated>2022-08-25T09:30:50Z</updated>
<author>
<name>Karthik Alapati</name>
<email>mail@karthek.com</email>
</author>
<published>2022-07-28T15:43:17Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=a5623a203cffe2d2b84d2f6c989d9017db1856af'/>
<id>urn:sha1:a5623a203cffe2d2b84d2f6c989d9017db1856af</id>
<content type='text'>
Free the buffered reports before deleting the list entry.

BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
  comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
  hex dump (first 32 bytes):
    64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00  d..j............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff814ac6c3&gt;] kmemdup+0x23/0x50 mm/util.c:128
    [&lt;ffffffff8357c1d2&gt;] kmemdup include/linux/fortify-string.h:440 [inline]
    [&lt;ffffffff8357c1d2&gt;] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
    [&lt;ffffffff8356ddad&gt;] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
    [&lt;ffffffff8356e41e&gt;] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
    [&lt;ffffffff835f0d3f&gt;] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
    [&lt;ffffffff82d3c7f9&gt;] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
    [&lt;ffffffff82d3cc26&gt;] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
    [&lt;ffffffff82ef1e14&gt;] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
    [&lt;ffffffff812f50a8&gt;] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
    [&lt;ffffffff812f5586&gt;] expire_timers kernel/time/timer.c:1519 [inline]
    [&lt;ffffffff812f5586&gt;] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
    [&lt;ffffffff812f56e4&gt;] __run_timers kernel/time/timer.c:1768 [inline]
    [&lt;ffffffff812f56e4&gt;] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
    [&lt;ffffffff848000e6&gt;] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
    [&lt;ffffffff81246db0&gt;] invoke_softirq kernel/softirq.c:445 [inline]
    [&lt;ffffffff81246db0&gt;] __irq_exit_rcu kernel/softirq.c:650 [inline]
    [&lt;ffffffff81246db0&gt;] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
    [&lt;ffffffff84574f02&gt;] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
    [&lt;ffffffff84600c8b&gt;] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
    [&lt;ffffffff8458a070&gt;] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
    [&lt;ffffffff8458a070&gt;] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554

Link: https://syzkaller.appspot.com/bug?id=19a04b43c75ed1092021010419b5e560a8172c4f
Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com
Signed-off-by: Karthik Alapati &lt;mail@karthek.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
</entry>
</feed>
