> CVE-2023-52478 [MEDIUM]

« BACK_TO_HOME
PUBLISHED
2024-02-29 06:15
MODIFIED
2025-01-10 18:27
CVSS_SCORE V3
4.7
EPSS (Prob. Exploit)
0.25%
Top 83.0%
DATA SOURCES:
NVD 🔗 2025-10-18 CVE PROJECT 🔗 2026-01-19 FIRST EPSS 🔗 2026-11-08 OSV 🔗 2026-11-08

> DESCRIPTION

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 sequence: 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); ... 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); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---

> AFFECTED_PRODUCTS

Linux - Linux Kernel
< 4.14.328
Linux - Linux Kernel
>= 4.15 < 4.19.297
Linux - Linux Kernel
>= 4.20 < 5.4.259
Linux - Linux Kernel
>= 5.5 < 5.10.199
Linux - Linux Kernel
>= 5.11 < 5.15.136
Linux - Linux Kernel
>= 5.16 < 6.1.59
Linux - Linux Kernel
>= 6.2 < 6.5.8
Linux - Linux Kernel
Version: 6.6

> CVSS V3 METRICS

CVSS_VECTOR
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

> MÉTRIQUES CVSS DÉTAILLÉES

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Métrique Valeur Interprétation
AV (Vecteur d'Attaque)
Attack Vector
Local (L)
Exploit nécessite un accès local au système
AC (Complexité d'Attaque)
Attack Complexity
High (H)
Conditions spécifiques doivent être réunies pour exploiter
PR (Privilèges Requis)
Privileges Required
Low (L)
Authentifié avec compte utilisateur basique
UI (Interaction Utilisateur)
User Interaction
None (N)
Aucune interaction utilisateur nécessaire
S (Périmètre)
Scope
Unchanged (U)
Impact reste dans le périmètre du composant compromis
C (Impact Confidentialité)
Confidentiality Impact
None (N)
Aucune divulgation d'informations
I (Impact Intégrité)
Integrity Impact
None (N)
Aucune modification de données possible
A (Impact Disponibilité)
Availability Impact
High (H)
Interruption totale du service possible

> RÉSUMÉ DES IMPACTS

Confidentialité
None
Aucune divulgation d'informations
Intégrité
None
Aucune modification de données possible
Disponibilité
High
Interruption totale du service possible

> OSV (GOOGLE OPEN SOURCE VULNERABILITIES)

HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect

AFFECTED PACKAGES:
Unknown / Unknown
Linux / Kernel

> HISTORIQUE DES MODIFICATIONS

Première apparition
29/02/2024 06:15
Source: NVD
📊 ENRICHISSEMENT 18/10/2025 14:46
CVEPROJECT
Champ modifié: CVE Project
Ancienne valeur:
Non
Nouvelle valeur:
Oui
Total des modifications: 1 Dernière mise à jour: 1 year ago
« BACK_TO_HOME