Linux Kernel bis 6.5.7 auf USB logitech-hidpp hidpp_connect_event Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
4.6$0-$5k0.00

Zusammenfassunginfo

Es wurde eine als kritisch klassifizierte Schwachstelle in Linux Kernel bis 6.5.7 auf USB entdeckt. Es geht hierbei um die Funktion hidpp_connect_event der Komponente logitech-hidpp. Mittels dem Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Sicherheitslücke ist unter CVE-2023-52478 bekannt. Es steht kein Exploit zur Verfügung. Es wird geraten, die betroffene Komponente zu aktualisieren.

Detailsinfo

In Linux Kernel bis 6.5.7 auf USB (Operating System) wurde eine Schwachstelle entdeckt. Sie wurde als kritisch eingestuft. Das betrifft die Funktion hidpp_connect_event der Komponente logitech-hidpp. Durch das Manipulieren mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-404. Mit Auswirkungen muss man rechnen für die Verfügbarkeit. CVE fasst zusammen:

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---

Die Schwachstelle wurde am 29.02.2024 an die Öffentlichkeit getragen. Das Advisory kann von git.kernel.org heruntergeladen werden. Eine eindeutige Identifikation der Schwachstelle wird seit dem 20.02.2024 mit CVE-2023-52478 vorgenommen. Technische Details sind bekannt, ein verfügbarer Exploit hingegen nicht.

Für den Vulnerability Scanner Nessus wurde ein Plugin mit der ID 207773 (Oracle Linux 8 : kernel (ELSA-2024-7000)) herausgegeben, womit die Existenz der Schwachstelle geprüft werden kann.

Ein Upgrade auf die Version 4.14.328, 4.19.297, 5.4.259, 5.10.199, 5.15.136, 6.1.59, 6.5.8 oder 6.6 vermag dieses Problem zu beheben. Die Schwachstelle lässt sich auch durch das Einspielen des Patches ca0c4cc1d215/44481b244fca/cd0e2bf7fb22/093af62c0235/28ddc1e0b898/fd72ac9556a4/f7b2c7d9831a/dac501397b9d beheben. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Aktualisieren auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von Tenable (207773) dokumentiert. Once again VulDB remains the best source for vulnerability data.

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 4.8
VulDB Meta Temp Score: 4.6

VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 4.7
NVD Vector: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔍
Status: Nicht definiert

EPSS Score: 🔍
EPSS Percentile: 🔍

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Nessus ID: 207773
Nessus Name: Oracle Linux 8 : kernel (ELSA-2024-7000)

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 4.14.328/4.19.297/5.4.259/5.10.199/5.15.136/6.1.59/6.5.8/6.6
Patch: ca0c4cc1d215/44481b244fca/cd0e2bf7fb22/093af62c0235/28ddc1e0b898/fd72ac9556a4/f7b2c7d9831a/dac501397b9d

Timelineinfo

20.02.2024 🔍
29.02.2024 +9 Tage 🔍
29.02.2024 +0 Tage 🔍
10.01.2025 +316 Tage 🔍

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2023-52478 (🔍)
GCVE (CVE): GCVE-0-2023-52478
GCVE (VulDB): GCVE-100-255196

Eintraginfo

Erstellt: 29.02.2024 08:09
Aktualisierung: 10.01.2025 23:19
Anpassungen: 29.02.2024 08:09 (45), 28.09.2024 10:36 (17), 10.01.2025 23:19 (10)
Komplett: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Interested in the pricing of exploits?

See the underground prices here!