Linux Kernel hasta 5.19.7 USB usb_gadget_disconnect denegación de servicio

| CVSS Puntuación meta temporal | Precio actual del exploit (≈) | Puntuación de interés CTI |
|---|---|---|
| 5.5 | $0-$5k | 0.00 |
Resumen
Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 5.19.7. Resulta afectada una función desconocida dentro del componente USB. Por la manipulación de un input desconocido se causa una vulnerabilidad de clase denegación de servicio. Esta vulnerabilidad se cataloga como CVE-2022-49943. No se encuentra disponible ningún exploit. Se aconseja actualizar el componente afectado.
Detalles
Una vulnerabilidad clasificada como crítica fue encontrada en Linux Kernel hasta 5.19.7. La función usb_gadget_disconnect del componente USB 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. El resumen de CVE es:
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: gadget: Se corrige una oscura violación de lockdep para udc_mutex. Una confirmación reciente que expandió el alcance del mutex udc_lock en el núcleo del gadget logró causar una oscura y ligeramente extraña violación de lockdep. En forma abreviada: ======================================================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 5.19.0-rc7+ #12510 No contaminado ------------------------------------------------------ udevadm/312 está intentando adquirir el bloqueo: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, en: usb_udc_uevent+0x54/0xe0 pero la tarea ya tiene el bloqueo: ffff000002277548 (kn->active#4){++++}-{0:0}, en: kernfs_seq_start+0x34/0xe0 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (mutex_lista_regulador){+.+.}-{3:3}: adquisición_bloqueo+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidentemente, esto se debió a que el alcance de udc_mutex era demasiado grande. El mutex solo protege udc->driver, entre otras cosas. Hasta donde sé, no hay razón para que el mutex se mantenga mientras el núcleo del gadget llama a la rutina ->bind o ->unbind de un controlador de gadget, ni mientras se inicia o detiene un UDC. (Esto explica el enlace n.º 1 de la cadena anterior, donde el mutex se mantiene mientras se inicia dwc2_hsotg_udc como parte del sondeo del controlador). Las devoluciones de llamada ->disconnect de los controladores de gadget son problemáticas. Aunque usb_gadget_disconnect() ahora adquirirá el udc_mutex, existe un margen en usb_gadget_bind_driver() entre el momento en que se libera el mutex y se invoca la devolucion de llamada ->bind. Si se produjera una desconexión durante ese margen, podríamos llamar a la rutina ->disconnect del controlador antes que a su rutina ->bind. Para evitarlo, será necesario impedir que un UDC se conecte mientras no tenga un controlador de gadget. Esto ya debería estar hecho, pero no parece estarlo; actualmente, usb_gadget_connect() no lo comprueba. Esta comprobación deberá añadirse más adelante. Se requiere cierto grado de exclusión mutua en soft_connect_store(), que puede desreferenciar udc->driver en cualquier momento, ya que es una devolución de llamada de sysfs. La solución es adquirir el bloqueo del dispositivo del gadget en lugar del udc_mutex. Dado que el núcleo del controlador garantiza que el bloqueo del dispositivo se mantenga siempre durante la vinculación y desvinculación del controlador, esto hará que los accesos en soft_connect_store() sean mutuamente excluyentes con cualquier cambio en udc->driver. Por último, resulta que hay un lugar que debería contener el udc_mutex, pero actualmente no lo hace: la rutina function_show() necesita protección mientras desreferencia udc->driver. Se añaden las llamadas de bloqueo y desbloqueo que faltan.El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2022-49943. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.
Una actualización a la versión 5.19.8 elimina esta vulnerabilidad. Aplicando el parche 1a065e4673cbdd9f222a05f85e17d78ea50c8d9c/1016fc0c096c92dd0e6e0541daac7a7868169903 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 CERT Bund (WID-SEC-2025-1350). Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Afectado
- Debian Linux
- Amazon Linux 2
- Red Hat Enterprise Linux
- Ubuntu Linux
- SUSE Linux
- Oracle Linux
- SUSE openSUSE
- Open Source Linux Kernel
- RESF Rocky Linux
- Dell Avamar
- Dell NetWorker
- Dell Secure Connect Gateway
- IBM QRadar SIEM
Producto
Escribe
Proveedor
Nombre
Versión
Licencia
Sitio web
- Proveedor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Confiabilidad: 🔍
CVSSv3
VulDB Puntuación meta base: 5.6VulDB Puntuación meta temporal: 5.5
VulDB Puntuación base: 5.7
VulDB Puntuación temporal: 5.5
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍
NVD Puntuación base: 5.5
NVD Vector: 🔍
CVSSv2
| 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ón
Clase: Denegación de servicioCWE: CWE-476 / 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 |
Inteligencia de amenazas
Interés: 🔍Actores activos: 🔍
Grupos APT activos: 🔍
Contramedidas
Recomendación: ActualizaciónEstado: 🔍
Hora de 0 días: 🔍
Actualización: Kernel 5.19.8
Parche: 1a065e4673cbdd9f222a05f85e17d78ea50c8d9c/1016fc0c096c92dd0e6e0541daac7a7868169903
Línea de tiempo
2025-06-18 🔍2025-06-18 🔍
2025-06-18 🔍
2025-11-30 🔍
Fuentes
Proveedor: kernel.orgAviso: git.kernel.org
Estado: Confirmado
CVE: CVE-2022-49943 (🔍)
GCVE (CVE): GCVE-0-2022-49943
GCVE (VulDB): GCVE-100-312913
CERT Bund: WID-SEC-2025-1350 - Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service
Artículo
Fecha de creación: 2025-06-18 14:21Actualizado: 2025-11-30 14:27
Cambios: 2025-06-18 14:21 (59), 2025-07-17 17:40 (7), 2025-07-29 01:05 (1), 2025-09-08 01:18 (1), 2025-09-26 04:31 (1), 2025-10-01 12:30 (1), 2025-11-15 04:17 (11), 2025-11-30 14:27 (1)
Completo: 🔍
Cache ID: 216::103
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Sin comentarios aún. Idiomas: es + pt + en.
Por favor, inicie sesión para comentar.