CVE-2023-52478
published 2024-02-29CVE-2023-52478: In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has…
PriorityP417medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.25%
16.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.
hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocol_major) {
hidpp_root_get_protocol_version()
hidpp->protocol_major = response.rap.params[0];
}
We can actually see this race hit in the dmesg in the abrt output
attached to rhbz#2227968:
[ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
[ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected.
Testing with extra logging added has shown that after this the 2 threads
take turn grabbing the hw access mutex (send_mutex) so they ping-pong
through all the other TOCTOU cases managing to hit all of them:
2. Updating the name to the HIDPP name (harmless race):
if (hidpp->name == hdev->name) {
...
hidpp->name = new_name;
}
3. Initializing the power_supply class for the battery (problematic!):
hidpp_initialize_battery()
{
if (hidpp->battery.ps)
return 0;
probe_battery(); /* Blocks, threads take turns executing this */
hidpp->battery.desc.properties =
devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL);
hidpp->battery.ps =
devm_power_supply_register(&hidpp->hid_dev->dev,
&hidpp->battery.desc, cfg);
}
4. Creating delayed input_device (potentially problematic):
if (hidpp->delayed_input)
return;
hidpp->delayed_input = hidpp_allocate_input(hdev);
The really big problem here is 3. Hitting the race leads to the following
seq
Affected
26 ranges· showing 25
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.64-1 (bookworm) | linux 6.1.64-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 | ca0c4cc1d215dc22ab0e738c9f017c650f3183f5 |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < 44481b244fcaa2b895a53081d6204c574720c38c | 44481b244fcaa2b895a53081d6204c574720c38c |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b | cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < 093af62c023537f097d2ebdfaa0bc7c1a6e874e1 | 093af62c023537f097d2ebdfaa0bc7c1a6e874e1 |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < 28ddc1e0b898291323b62d770b1b931de131a528 | 28ddc1e0b898291323b62d770b1b931de131a528 |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < fd72ac9556a473fc7daf54efb6ca8a97180d621d | fd72ac9556a473fc7daf54efb6ca8a97180d621d |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < f7b2c7d9831af99369fe8ad9b2a68d78942f414e | f7b2c7d9831af99369fe8ad9b2a68d78942f414e |
| linux | linux | >= c39e3d5fc9dd3e16c6f59dd94d827540040de66d < dac501397b9d81e4782232c39f94f4307b137452 | dac501397b9d81e4782232c39f94f4307b137452 |
| linux | linux_kernel | < 4.14.328 | 4.14.328 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.205-1 | 5.10.205-1 |
| linux | linux_kernel | >= 0 < 6.1.64-1 | 6.1.64-1 |
| linux | linux_kernel | >= 0 < 6.5.8-1 | 6.5.8-1 |
| linux | linux_kernel | >= 0 < 6.5.8-1 | 6.5.8-1 |
| linux | linux_kernel | >= 4.15 < 4.19.297 | 4.19.297 |
| linux | linux_kernel | >= 4.20 < 5.4.259 | 5.4.259 |
| linux | linux_kernel | >= 5.11 < 5.15.136 | 5.15.136 |
| linux | linux_kernel | >= 5.16 < 6.1.59 | 6.1.59 |
| linux | linux_kernel | >= 5.5 < 5.10.199 | 5.10.199 |
CVSS provenance
nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_debian4.7MEDIUM
vendor_redhat4.7MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
CISA ICS
Siemens SINEC OS
cisa_ics·2025-08-14
Siemens SINEC OS
ICS Advisory
##
Siemens SINEC OS
Release DateAugust 14, 2025
Alert CodeICSA-25-226-15
Related topics:
Industrial Control System Vulnerabilities, Industrial Control Systems
As of January 10, 2023, CISA will no longer be updating ICS security advisories for Siemens product vulnerabilities beyond the initial advisory. For the most up-to-date information on vulnerabilities in this advisory, please see Siemens' ProductCERT Security Advisories (CERT Services | Services | Siemens Global).
View CSAF
## 1. EXECUTIVE SUMMARY
- CVSS v3.1 9.1
- ATTENTION: Exploitable remotely/low attack complexity
- Vendor: Siemens
- Equipment: RUGGEDCOM, SCALANCE
- Vulnerabilities: NULL Pointer Dereference, Use After Free, Unchecked Input for Loop Condition, Out-of-bounds Write, Ou
Red Hat
kernel: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
vendor_redhat·2024-02-29·CVSS 4.7
CVE-2023-52478 [MEDIUM] CWE-362 kernel: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
kernel: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.
hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocol_major) {
hidpp_root_get_protocol_versi
Debian
CVE-2023-52478: linux - In the Linux kernel, the following vulnerability has been resolved: HID: logite...
vendor_debian·2023·CVSS 4.7
CVE-2023-52478 [MEDIUM] CVE-2023-52478: linux - In the Linux kernel, the following vulnerability has been resolved: HID: logite...
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see
OSV
CVE-2023-52478: In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_eve
osv·2024-02-29·CVSS 4.7
CVE-2023-52478 [MEDIUM] CVE-2023-52478: In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_eve
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see
GHSA
GHSA-f7hm-xqp4-h2q8: In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_e
ghsa_unreviewed·2024-02-29
CVE-2023-52478 [MEDIUM] CWE-367 GHSA-f7hm-xqp4-h2q8: In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_e
In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect
hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU)
races when it races with itself.
hidpp_connect_event() primarily runs from a workqueue but it also runs
on probe() and if a "device-connected" packet is received by the hw
when the thread running hidpp_connect_event() from probe() is waiting on
the hw, then a second thread running hidpp_connect_event() will be
started from the workqueue.
This opens the following races (note the below code is simplified):
1. Retrieving + printing the protocol (harmless race):
if (!hidpp->protocol_major) {
hidpp_root_get_protocol_version()
hidpp->protocol_major = response.rap.params[0];
}
We can actua
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38chttps://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6bhttps://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414ehttps://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621dhttps://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38chttps://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6bhttps://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414ehttps://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d
2024-02-29
Published