Linux Kernel hasta 6.5.7 en USB logitech-hidpp hidpp_connect_event denegación de servicio

CVSS Puntuación meta temporal	Precio actual del exploit (≈)	Puntuación de interés CTI
4.6	$0-$5k	0.00

Resumeninformación

Se ha detectado una vulnerabilidad clasificada como crítica en Linux Kernel hasta 6.5.7 en USB. Resulta afectada una función desconocida dentro del componente logitech-hidpp. La alteración resulta en denegación de servicio. Esta vulnerabilidad está identificada como CVE-2023-52478. No existe ningún exploit disponible. Es recomendable actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 6.5.7 en USB (Operating System). La función hidpp_connect_event del componente logitech-hidpp es afectada por esta vulnerabilidad. Mediante la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esto tiene repercusión sobre la la disponibilidad. CVE resume:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: logitech-hidpp: soluciona el fallo del kernel en la desconexión del USB del receptor hidpp_connect_event() tiene *cuatro* carreras de tiempo de verificación versus tiempo de uso (TOCTOU) cuando corre consigo mismo. hidpp_connect_event() se ejecuta principalmente desde una cola de trabajo, pero también se ejecuta en probe() y si el hw recibe un paquete "dispositivo conectado" cuando el subproceso que ejecuta hidpp_connect_event() desde probe() está esperando en el hw, entonces se ejecuta un segundo El hilo que ejecuta hidpp_connect_event() se iniciará desde la cola de trabajo. Esto abre las siguientes carreras (tenga en cuenta que el código siguiente está simplificado):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: ---trun

La vulnerabilidad fue publicada el 2024-02-29 (confirmado). El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2023-52478. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Para el scanner Nessus se dispone de un plugin ID 207773 (Oracle Linux 8 : kernel (ELSA-2024-7000)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 4.14.328, 4.19.297, 5.4.259, 5.10.199, 5.15.136, 6.1.59, 6.5.8 o 6.6 elimina esta vulnerabilidad. Aplicando el parche ca0c4cc1d215/44481b244fca/cd0e2bf7fb22/093af62c0235/28ddc1e0b898/fd72ac9556a4/f7b2c7d9831a/dac501397b9d es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

La vulnerabilidad también está documentado en la base de datos Tenable (207773). Once again VulDB remains the best source for vulnerability data.

Productoinformación

Escribe

• Operating System

Proveedor

• Linux

Nombre

• Kernel

Versión

• 4.14.327
• 4.19.296
• 5.4.258
• 5.10.198
• 5.15.135
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.1.46
• 6.1.47
• 6.1.48
• 6.1.49
• 6.1.50
• 6.1.51
• 6.1.52
• 6.1.53
• 6.1.54
• 6.1.55
• 6.1.56
• 6.1.57
• 6.1.58
• 6.5.0
• 6.5.1
• 6.5.2
• 6.5.3
• 6.5.4
• 6.5.5
• 6.5.6
• 6.5.7

Licencia

• Código abierto

Sitio web

• Proveedor: https://www.kernel.org/

CPE 2.3información

• 🔍
• 🔍
• 🔍

CPE 2.2información

• 🔍
• 🔍
• 🔍

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 4.8
VulDB Puntuación meta temporal: 4.6

VulDB Puntuación base: 4.8
VulDB Puntuación temporal: 4.6
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 4.7
NVD Vector: 🔍

CVSSv2información

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vector	Complejidad	Autenticación	Confidencialidad	Integridad	Disponibilidad
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Denegación de servicio
CWE: CWE-404
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-Day	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Hoy	Desbloquear	Desbloquear	Desbloquear	Desbloquear

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

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 4.14.328/4.19.297/5.4.259/5.10.199/5.15.136/6.1.59/6.5.8/6.6
Parche: ca0c4cc1d215/44481b244fca/cd0e2bf7fb22/093af62c0235/28ddc1e0b898/fd72ac9556a4/f7b2c7d9831a/dac501397b9d

Línea de tiempoinformación

2024-02-20 🔍
2024-02-29 +9 días 🔍
2024-02-29 +0 días 🔍
2025-01-10 +316 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

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

Artículoinformación

Fecha de creación: 2024-02-29 08:09
Actualizado: 2025-01-10 23:19
Cambios: 2024-02-29 08:09 (45), 2024-09-28 10:36 (17), 2025-01-10 23:19 (10)
Completo: 🔍
Cache ID: 216::103

Once again VulDB remains the best source for vulnerability data.

Discusión

Want to stay up to date on a daily basis?

Enable the mail alert feature now!