Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

Vulnerabilidad en kernel de Linux (CVE-2024-53183)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: um: net: No utilizar drvdata en la versión El archivo drvdata no está disponible en la versión. Simplemente usemos Container_of() para obtener la instancia de Uml_net. De lo contrario, eliminar un dispositivo de red provocará un bloqueo: RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Pánico del núcleo: no se sincroniza: error de segmentación sin mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 No contaminado 6.12.0-rc6-g59b723cd2adb #1 Cola de trabajo: eventos mc_work_proc Pila: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Seguimiento de llamadas: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] proceso_trabajos_programados+0x1b3/0x2dd [<60055f32>] ? asignar_trabajo+0x0/0x58 [<60057f0a>] subproceso_trabajador+0x1e9/0x293 [<6005406f>] ? establecer_pf_trabajador+0x0/0x64 [<6005d65d>] ? guardar_irq_local_arch+0x0/0x2d [<6005d748>] ? salir_kthread+0x0/0x3a [<60057d21>] ? subproceso_de_trabajo+0x0/0x293 [<6005dbf1>] subproceso_de_trabajo+0x126/0x12b [<600219c5>] nuevo_controlador_de_subprocesos+0x85/0xb6
Vulnerabilidad en kernel de Linux (CVE-2024-53184)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad: um: ubd: No utilizar drvdata en la versión El archivo drvdata no está disponible en la versión. Simplemente usemos contenedor_of() para obtener la instancia ubd. De lo contrario, eliminar un dispositivo ubd provocará un bloqueo: RIP: 0033:blk_mq_free_tag_set+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Pánico del núcleo: no se sincroniza: error de segmentación sin mm CPU: 0 PID: 17 Comm: kworker/0:1 No contaminado 6.8.0-rc3-00107-gba3f67c11638 #1 Cola de trabajo: eventos mc_work_proc Pila: 00000000 604f7ef0 Rastreo de llamadas: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] proceso_trabajos_programados+0x1af/0x2c3 [<6004ede3>] ? asignar_trabajo+0x0/0x58 [<600527a1>] subproceso_trabajador+0x2f7/0x37a [<6004ee3b>] ? establecer_pf_trabajador+0x0/0x64 [<6005765d>] ? guardar_irq_local_arch+0x0/0x2d [<60058e07>] ? salir_kthread+0x0/0x3a [<600524aa>] ? subproceso_de_trabajo+0x0/0x37a [<60058f9f>] subproceso_de_trabajo+0x130/0x135 [<6002068e>] nuevo_controlador_de_subprocesos+0x85/0xb6
Vulnerabilidad en kernel de Linux (CVE-2024-53189)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan La matriz channels en cfg80211_scan_request tiene un atributo __counted_by adjunto, que apunta a la variable n_channels. Este atributo se utiliza en la comprobación de los límites y, si no se configura antes de que se complete la matriz, el desinfectante de los límites emitirá una advertencia o un pánico del kernel si se configura CONFIG_UBSAN_TRAP. Este parche establece el tamaño de la memoria asignada como el valor inicial para n_channels. Se actualiza con el número real de elementos agregados después de que se complete la matriz.
Vulnerabilidad en kernel de Linux (CVE-2024-53211)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/l2tp: corrección de advertencia en l2tp_exit_net encontrada por syzbot En el controlador de salida de red de l2tp, verificamos que un IDR esté vacío antes de destruirlo: WARN_ON_ONCE(!idr_is_empty(&pn->l2tp_tunnel_idr)); idr_destroy(&pn->l2tp_tunnel_idr); Al forzar fallas de asignación de memoria en idr_alloc_32, syzbot puede provocar una condición donde idr_is_empty devuelve falso a pesar de que no haya elementos en el IDR. Esto resulta ser porque el árbol de radix del IDR contiene solo nodos de árbol de radix internos y es esto lo que hace que idr_is_empty devuelva falso. Los nodos internos son limpiados por idr_destroy. Utilice idr_for_each para verificar que el IDR esté vacío en lugar de idr_is_empty para evitar el problema.
Vulnerabilidad en kernel de Linux (CVE-2024-53212)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: corrige la advertencia de falso positivo en extack durante los volcados Commit bajo corrige el informe extendido de extack a los volcados. Funciona en condiciones normales, porque los errores de extack generalmente se informan durante ->start() o el primer ->dump(), es bastante raro que el volcado comience bien pero falle más tarde. Sin embargo, si el volcado falla más tarde, el skb de entrada ya tendrá el mensaje de inicio extraído, por lo que la verificación de si el atributo incorrecto cae dentro de skb->data fallará. Cambie la verificación para usar nlh, que siempre es válido. syzbot encontró una forma de abordar ese escenario llenando la cola de recepción. En este caso, iniciamos un volcado pero no llamamos a ->dump() hasta que haya espacio de lectura para un skb. ADVERTENCIA: CPU: 1 PID: 5845 en net/netlink/af_netlink.c:2210 netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 RIP: 0010:netlink_ack_tlv_fill+0x1a8/0x560 net/netlink/af_netlink.c:2209 Seguimiento de llamadas: netlink_dump_done+0x513/0x970 net/netlink/af_netlink.c:2250 netlink_dump+0x91f/0xe10 net/netlink/af_netlink.c:2351 netlink_recvmsg+0x6bb/0x11d0 net/netlink/af_netlink.c:1983 sock_recvmsg_nosec net/socket.c:1051 [en línea] sock_recvmsg+0x22f/0x280 net/socket.c:1073 __sys_recvfrom+0x246/0x3d0 net/socket.c:2267 __do_sys_recvfrom net/socket.c:2285 [en línea] __se_sys_recvfrom net/socket.c:2281 [en línea] __x64_sys_recvfrom+0xde/0x100 net/socket.c:2281 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ff37dd17a79
Vulnerabilidad en kernel de Linux (CVE-2024-53223)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: ralink: mtmips: corrige el orden de sondeo de los relojes en los SoC ralink más antiguos Los relojes base son los primeros en ser sondeados y son dependencias reales del resto de relojes fijos, de factor y periféricos. Para los antiguos SoCs ralink RT2880, RT305x y RT3883, se debe definir primero 'xtal' ya que en cualquier otro caso, cuando se prueban relojes fijos, se retrasan hasta que se prueba 'xtal', por lo que aparece la siguiente advertencia: ADVERTENCIA: CPU: 0 PID: 0 en drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138 Módulos vinculados en: CPU: 0 PID: 0 Comm: swapper No contaminado 6.6.43 #0 Pila: 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000 ... Seguimiento de llamadas: [<800065d0>] show_stack+0x64/0xf4 [<804bca14>] dump_stack_lvl+0x38/0x60 [<800218ac>] __warn+0x94/0xe4 [<8002195c>] warn_slowpath_fmt+0x60/0x94 [<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138 [<80254530>] __clk_register+0x568/0x688 [<80254838>] of_clk_hw_register+0x18/0x2c [<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594 [<8070b628>] of_clk_init+0x1c0/0x23c [<806fc448>] plat_time_init+0x58/0x18c [<806fdaf0>] time_init+0x10/0x6c [<806f9bc4>] start_kernel+0x458/0x67c ---[ fin de seguimiento 0000000000000000 ]--- Cuando se incorporó este controlador, no pudimos encontrar ningún usuario activo de SoC ralink antiguos, por lo que no podemos realizar ninguna prueba real para ellos. Ahora, un usuario de un dispositivo Belkin f9k1109 versión 1 que usa RT3883 SoC apareció y reportó algunos problemas en openWRT: - https://github.com/openwrt/openwrt/issues/16054 Por lo tanto, defina un 'rt2880_xtal_recalc_rate()' que simplemente devuelva la frecuencia esperada de 40Mhz y úselo junto con los viejos SoC ralink para tener un seguimiento de arranque correcto sin advertencias y un plan de reloj que funcione desde el principio.
Vulnerabilidad en kernel de Linux (CVE-2024-53229)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: se han corregido las advertencias de vaciado de qp en req. Cuando el qp está en estado de error, el estado de los WQE en la cola debe establecerse en error. De lo contrario, aparecerá lo siguiente. [ 920.617269] ADVERTENCIA: CPU: 1 PID: 21 en drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.617744] Módulos vinculados en: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6 [ 920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Contaminado: GO 6.1.113-storage+ #65 [ 920.618986] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe] [ 920.619658] Código: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24 [ 920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246 [ 920.620817] RAX: 000000000000000 RBX: 000000000000000c RCX: 0000000000000008 [ 920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac [ 920.621548] RBP: 00000000000000000 R08: 00000000000000001 R09: ffffffffac406450 [ 920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800 [ 920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 000000000000000 [ 920.622609] FS: 0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000 [ 920.622979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0 [ 920.623680] Rastreo de llamadas: [ 920.623815] [ 920.623933] ? __warn+0x79/0xc0 [ 920.624116] ? asm_exc_invalid_op+0x16/0x20 [ 920.625203] ? rxe_cq_post+0xe2/0x180 [rdma_rxe] [ 920.626583] ? do_complete+0x18d/0x220 [rdma_rxe] [ 920.626812] ? rxe_completer+0x1a3/0xcc0 [rdma_rxe] [ 920.627050] rxe_do_task+0x80/0x110 [rdma_rxe] [ 920.627285] tasklet_action_common.constprop.0+0xa4/0x120 [ 920.627522] handle_softirqs+0xc2/0x250 [ 920.627728] ? rango_de_ordenación+0x20/0x20 [ 920.627942] ejecutar_ksoftirqd+0x1f/0x30 [ 920.628158] función_de_subproceso_de_arranque_smp+0xc7/0x1b0 [ 920.628334] subproceso_k+0xd6/0x100 [ 920.628504] ? kthread_completar_y_salir+0x20/0x20 [ 920.628709] retirar_de_la_bifurcación+0x1f/0x30 [ 920.628892]
Vulnerabilidad en kernel de Linux (CVE-2024-53234)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: gestiona lclusters NONHEAD !delta[1] con gracia syzbot informó una ADVERTENCIA en iomap_iter_done: iomap_fiemap+0x73b/0x9b0 fs/iomap/fiemap.c:80 ioctl_fiemap fs/ioctl.c:220 [en línea] Generalmente, los lclusters NONHEAD no tendrán delta[1]==0, excepto para imágenes y sistemas de archivos creados por versiones de mkfs anteriores a la 1.0. Anteriormente, se cancelaba inmediatamente si delta[1]==0, lo que provocaba longitudes descomprimidas inadecuadas (por lo tanto, FIEMAP se ve afectado). Trátelo como delta[1]=1 para solucionar estas versiones heredadas de mkfs. `lclusterbits > 14` es ilegal para índices compactos, también genera un error.
Vulnerabilidad en kernel de Linux (CVE-2024-53236)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: liberar skb cuando las opciones de metadatos TX no son válidas Cuando se asigna un nuevo skb para transmitir un descriptor xsk, es decir, para cada descriptor que no sea multibuf o el primer fragmento de un descriptor multibuf, pero luego se descubre que el descriptor tiene opciones no válidas establecidas para los metadatos TX, el nuevo skb nunca se libera. Esto puede filtrar skbs hasta que el búfer de envío esté lleno, lo que hace imposible enviar más paquetes. Solucione esto liberando el skb en la ruta de error si actualmente estamos tratando con el primer fragmento, es decir, un skb asignado en esta iteración de xsk_build_skb.
Vulnerabilidad en kernel de Linux (CVE-2024-56539)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: Se corrige la advertencia de escritura que abarca el campo memcpy() en mwifiex_config_scan() Reemplace la matriz de un elemento con un miembro de matriz flexible en `struct mwifiex_ie_types_wildcard_ssid_params` para corregir la siguiente advertencia en una Chromebook MT8173 (mt8173-elm-hana): [ 356.775250] ------------[ cortar aquí ]------------ [ 356.784543] memcpy: se detectó escritura que abarca el campo (tamaño 6) del campo único "wildcard_ssid_tlv->ssid" en drivers/net/wireless/marvell/mwifiex/scan.c:904 (tamaño 1) [ 356.813403] ADVERTENCIA: CPU: 3 PID: 742 en drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex] El "(tamaño 6)" anterior es exactamente la longitud del SSID de la red a la que estaba conectado este dispositivo. La fuente de la advertencia se ve así: ssid_len = user_scan_in->ssid_list[i].ssid_len; [...] memcpy(wildcard_ssid_tlv->ssid, user_scan_in->ssid_list[i].ssid, ssid_len); Hay un #define WILDCARD_SSID_TLV_MAX_SIZE que usa sizeof() en esta estructura, pero ya no tenía en cuenta el tamaño de la matriz de un elemento, por lo que no es necesario cambiarlo.
Vulnerabilidad en kernel de Linux (CVE-2024-56543)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Omitir desinfección de TID de Rx para peer propio Durante la creación del peer, se realiza la configuración de dp para el peer donde se actualiza el TID de Rx para todos los TID. El objeto peer para el peer propio no pasará por la configuración de dp. Cuando el núcleo se detiene, se realiza la desinfección de dp para todos los peers. Durante la desinfección, se accede a rx_tid::ab, lo que provoca el siguiente seguimiento de pila para el peer propio. ADVERTENCIA: CPU: 6 PID: 12297 en drivers/net/wireless/ath/ath12k/dp_rx.c:851 Seguimiento de llamadas: __warn+0x7b/0x1a0 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] report_bug+0x10b/0x200 handle_bug+0x3f/0x70 exc_invalid_op+0x13/0x60 asm_exc_invalid_op+0x16/0x20 ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k] ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k] ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k] ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k] ath12k_core_halt+0x3b/0x100 [ath12k] ath12k_core_reset+0x494/0x4c0 [ath12k] El objeto sta en el peer se actualizará cuando se cree el peer remoto. Por lo tanto, use peer::sta para detectar el peer propio y omitir la desinfección. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Vulnerabilidad en kernel de Linux (CVE-2024-56545)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: hyperv: optimizar la sonda del controlador para evitar problemas con devres Se encontró que descargar el módulo 'hid_hyperv' da como resultado una queja de devres: ... hv_vmbus: anulando el registro del controlador hid_hyperv ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 3983 en drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Seguimiento de llamadas: ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? grupo_liberación_devres+0x1f2/0x2c0 ? grupo_liberación_devres+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_grupo_liberación_devres+0x10/0x10 eliminación_dispositivo_hid+0xf5/0x220 controlador_liberación_dispositivo_interno+0x371/0x540 ? klist_put+0xf3/0x170 eliminación_dispositivo_bus+0x1f1/0x3f0 dispositivo_del+0x33f/0x8c0 ? __pfx_dispositivo_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... Y el problema parece ser que el grupo devres correspondiente no está asignado. Normalmente, devres_open_group() se llama desde __hid_device_probe() pero el controlador HID de Hyper-V anula 'hid_dev->driver' con el stub 'mousevsc_hid_driver' y básicamente vuelve a implementar __hid_device_probe() llamando a hid_parse() y hid_hw_start() pero no a devres_open_group(). hid_device_probe() no llama a __hid_device_probe() para ello. Más tarde, cuando se elimina el controlador, hid_device_remove() llama a devres_release_group() ya que no verifica si hdev->driver se anuló inicialmente o no. El problema parece estar relacionado con el commit 62c68e7cee33 ("HID: garantizar la liberación oportuna de los recursos asignados al controlador") pero el commit en sí parece ser correcta. Solucione el problema eliminando la anulación de 'hid_dev->driver' y utilizando hid_register_driver()/hid_unregister_driver() en su lugar. Como alternativa, habría sido posible confiar en la gestión predeterminado, pero HID_CONNECT_DEFAULT implica HID_CONNECT_HIDRAW y no parece funcionar para mousevsc tal como está.
Vulnerabilidad en kernel de Linux (CVE-2024-56547)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rcu/nocb: Corregir la barrera RCU omitida al descargar Actualmente, ejecutar la prueba rcutorture con torture_type=rcu fwd_progress=8 n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60 test_boost=2, activará la siguiente advertencia: ADVERTENCIA: CPU: 19 PID: 100 en kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0 RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0 Rastreo de llamadas: ? __warn+0x7e/0x120 ? rcu_nocb_rdp_deoffload+0x292/0x2a0? report_bug+0x18e/0x1a0? handle_bug+0x3d/0x70? exc_invalid_op+0x18/0x70? asm_exc_invalid_op+0x1a/0x20? rcu_nocb_rdp_deoffload+0x292/0x2a0 rcu_nocb_cpu_deoffload+0x70/0xa0 rcu_nocb_toggle+0x136/0x1c0? __pfx_rcu_nocb_toggle+0x10/0x10 kthread+0xd1/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 CPU0 CPU2 CPU3 //rcu_nocb_toggle //nocb_cb_wait //rcutorture // desconecta la CPU1 // procesa el rdp de la CPU1 rcu_barrier() rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_do_batch() // invocar rdp->cblist de CPU1 // devolución de llamada rcu_barrier_callback() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // todavía se ve len == 2 // poner en cola la barrera // devolución de llamada a rdp->cblist de CPU1 rcu_segcblist_entrain() rcu_segcblist_add_len(1); // len == 3 // decrementar len rcu_segcblist_add_len(-2); kthread_parkme() // rdp->cblist de CPU1 len == 1 // Advertir porque todavía hay una barrera pendiente // activar la advertencia WARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist)); cpus_read_unlock(); // esperar a que la CPU1 se conecte e // invocar la devolución de llamada de barrera en // la CPU1 rdp's->cblist wait_for_completion(&rcu_state.barrier_completion); // descargar la CPU4 cpus_read_lock() rcu_barrier() mutex_lock(&rcu_state.barrier_mutex); // bloquear en barrier_mutex // esperar a que rcu_barrier() en // la CPU3 desbloquee barrier_mutex // pero la CPU3 desbloquea barrier_mutex // necesita esperar a que la CPU1 se conecte // cuando la CPU1 se conecte se bloqueará en cpus_write_lock El escenario anterior no solo activará un WARN_ON_ONCE(), sino que también activará un bloqueo. Gracias al bloqueo de nocb, un segundo rcu_barrier() en una CPU fuera de línea observará el contador de devolución de llamadas reducido a 0 y ahorrará la puesta en cola de devolución de llamadas, o rcuo observará la nueva devolución de llamada y mantendrá rdp->nocb_cb_sleep en falso. Por lo tanto, verifique rdp->nocb_cb_sleep antes de estacionar para asegurarse de que no haya más rcu_barrier() esperando en el rdp.
Vulnerabilidad en kernel de Linux (CVE-2024-56550)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/stacktrace: Utilizar break en lugar de la declaración return arch_stack_walk_user_common() contiene una declaración return en lugar de una declaración break en caso de que store_ip() falle al intentar almacenar una entrada de cadena de llamadas de un proceso de espacio de usuario. Esto puede provocar que falte una llamada pagefault_enable(). Si esto sucede, el controlador de fallas de página no resolverá ninguna falla de página posterior del proceso y esto, a su vez, provocará que se elimine el proceso. Utilice una declaración break en lugar de una declaración return para solucionar esto.
Vulnerabilidad en kernel de Linux (CVE-2024-56592)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Llamar a free_htab_elem() después de htab_unlock_bucket() Para htab de mapas, cuando el mapa se elimina del htab, puede contener la última referencia del mapa. bpf_map_fd_put_ptr() invocará bpf_map_free_id() para liberar el id del elemento del mapa eliminado. Sin embargo, bpf_map_fd_put_ptr() se invoca mientras se mantiene un bloqueo de depósito (raw_spin_lock_t), y bpf_map_free_id() intenta adquirir map_idr_lock (spinlock_t), lo que activa la siguiente advertencia de lockdep: ============================== [ ERROR: Contexto de espera no válido ] 6.11.0-rc4+ #49 No contaminado ----------------------------- test_maps/4881 está intentando bloquear: ffffffff84884578 (map_idr_lock){+...}-{3:3}, en: bpf_map_free_id.part.0+0x21/0x70 otra información que podría ayudarnos a depurar esto: context-{5:5} 2 bloqueos mantenidos por test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, en: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, en: htab_map_update_elem+0x178/0xa80 seguimiento de pila: CPU: 0 UID: 0 PID: 4881 Comm: test_maps No contaminado 6.11.0-rc4+ #49 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), ... Seguimiento de llamadas: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Una forma de corregir la advertencia de lockdep es usar raw_spinlock_t también para map_idr_lock. Sin embargo, bpf_map_alloc_id() invoca idr_alloc_cyclic() después de adquirir map_idr_lock, activará una advertencia de lockdep similar porque el bloqueo del slab (s->cpu_slab->lock) sigue siendo un spinlock. En lugar de cambiar el tipo de map_idr_lock, solucione el problema invocando htab_put_fd_value() después de htab_unlock_bucket(). Sin embargo, solo aplazar la invocación de htab_put_fd_value() no es suficiente, porque los punteros de mapa antiguos en htab de mapas no se pueden guardar durante la eliminación por lotes. Por lo tanto, también aplace la invocación de free_htab_elem(), para que estos elementos a liberar se puedan vincular entre sí de forma similar a lru map. Hay cuatro invocadores para ->map_fd_put_ptr: (1) alloc_htab_elem() (a través de htab_put_fd_value()) Invoca ->map_fd_put_ptr() bajo un raw_spinlock_t. La invocación de htab_put_fd_value() no se puede mover simplemente después de htab_unlock_bucket(), porque el elemento antiguo ya se ha almacenado en htab->extra_elems. Se puede reutilizar inmediatamente después de htab_unlock_bucket() y la invocación de htab_put_fd_value() después de htab_unlock_bucket() puede liberar el elemento recién agregado de manera incorrecta. Por lo tanto, se guarda el puntero del mapa del elemento antiguo para htab de mapas antes de desbloquear el depósito y se libera map_ptr después del desbloqueo. Además del puntero del mapa en el elemento antiguo, se debe hacer lo mismo para los campos especiales en el elemento antiguo también. (2) free_htab_elem() (a través de htab_put_fd_value()) Su llamador incluye __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() y __htab_map_lookup_and_delete_batch(). Para htab_map_delete_elem(), simplemente invoque free_htab_elem() después de htab_unlock_bucket(). Para __htab_map_lookup_and_delete_batch(), al igual que lru map, vinculando el elemento a liberar en la lista node_to_free e invocando free_htab_elem() para estos elementos después del desbloqueo. Es seguro reutilizar batch_flink como el enlace para node_to_free, ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-56594)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: establecer la limitación correcta del segmento sg AMDGPU El controlador debe establecer el max_segment_size correcto; de lo contrario, debug_dma_map_sg() se quejará sobre el sobremapeo de la longitud sg de AMDGPU de la siguiente manera: ADVERTENCIA: CPU: 6 PID: 1964 en kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370 [ 364.049444] Módulos vinculados en: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter superposición nvme_fabrics nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c puente stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl leds de entrada snd [ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Contaminado: G OE 6.10.0-custom #492 [ 364.049579] Nombre del hardware: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 13/06/2021 [ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370 [ 364.049585] Código: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05 [ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286 [ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027 [ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680 [ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930 [ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000 [ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800 [ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000 [ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0 [ 364.049605] Rastreo de llamadas: [ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80 [ 364.049614] ? __warn+0x8c/0x140 [ 364.049618] ? debug_dma_map_sg+0x2dc/0x370 [ 364.049621] ? report_bug+0x193/0x1a0 [ 364.049627] ? handle_bug+0x46/0x80 [ 364.049631] ? exc_invalid_op+0x1d/0x80 [ 364.049635] ? asm_exc_invalid_op+0x1f/0x30 [ 364.049642] ? srso_return_thunk+0x5/0x5f [364.049939] ? ttm_bo_handle_move_mem+0xc3/0x180 [ttm] [ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm] [ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu] [ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memoria_de_gpu+0xa12/0xc90 [amdgpu] [ 364.050473] kfd_ioctl_alloc_memoria_de_gpu+0x16b/0x3b0 [amdgpu] [ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu] [ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu] [ 364.05105 ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-56607)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: arregla llamadas atómicas en ath12k_mac_op_set_bitrate_mask() Cuando intento configurar manualmente las tasas de bits: iw wlan0 set bitrates legacy-2.4 1 Me aparece un error de suspensión por contexto no válido, consulte a continuación. Solucione eso cambiando al uso de ieee80211_iterate_stations_mtx() introducido recientemente. Tenga en cuenta que el firmware WCN6855 sigue fallando, no estoy seguro de si ese firmware incluso admite comandos WMI de tasa de bits y ¿deberíamos considerar deshabilitar ath12k_mac_op_set_bitrate_mask() para WCN6855? Pero eso es para otro parche. ERROR: función inactiva llamada desde un contexto no válido en drivers/net/wireless/ath/ath12k/wmi.c:420 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw preempt_count: 0, expected: 0 Profundidad de anidación de RCU: 1, expected: 0 3 bloqueos mantenidos por iw/2236: #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, en: genl_rcv+0x14/0x40 #1: ffff888138410810 (&rdev->wiphy.mtx){+.+.}-{3:3}, en: nl80211_pre_doit+0x54d/0x800 [cfg80211] #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, en: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211] CPU: 3 UID: 0 PID: 2236 Comm: iw No contaminado 6.11.0-rc7-wt-ath+ #1772 Nombre del hardware: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 28/05/2021 Seguimiento de llamadas: dump_stack_lvl+0xa4/0xe0 dump_stack+0x10/0x20 __might_resched+0x363/0x5a0 ? __alloc_skb+0x165/0x340 __might_sleep+0xad/0x160 ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k] ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k] ? __netdev_alloc_skb+0x45/0x7b0 ? __asan_memset+0x39/0x40 ? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k] ? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k] ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211] ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k] ? __this_cpu_preempt_check+0x13/0x20 nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211] ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211] ? trace_contention_end+0xef/0x140 ? rtnl_unlock+0x9/0x10 ? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211] ? genl_rcv_msg+0xa0/0x130 netlink_rcv_skb+0x14c/0x400 ? genl_family_rcv_msg+0x600/0x600 ? netlink_ack+0xd70/0xd70 ? rwsem_optimistic_spin+0x4f0/0x4f0 ? genl_rcv+0x14/0x40 ? down_read_killable+0x580/0x580 ? netlink_deliver_tap+0x13e/0x350 ? __esta_comprobación_previa_de_cpu+0x13/0x20 genl_rcv+0x23/0x40 netlink_unicast+0x45e/0x790 ? netlink_attachskb+0x7f0/0x7f0 netlink_sendmsg+0x7eb/0xdb0 ? netlink_unicast+0x790/0x790 ? __esta_comprobación_previa_de_cpu+0x13/0x20 ? selinux_socket_sendmsg+0x31/0x40 ? netlink_unicast+0x790/0x790 __sock_sendmsg+0xc9/0x160 ____sys_sendmsg+0x620/0x990 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x410/0x410 ? __kasan_check_read+0x11/0x20 ? mark_lock+0xe6/0x1470 ___sys_sendmsg+0xe9/0x170 ? copy_msghdr_from_user+0x120/0x120 ? __lock_acquire+0xc62/0x1de0 ? do_fault_around+0x2c6/0x4e0 ? do_user_addr_fault+0x8c1/0xde0 ? volver a adquirir bloqueos retenidos+0x220/0x4d0 ? do_user_addr_fault+0x8c1/0xde0 ? __kasan_check_read+0x11/0x20 ? __fdget+0x4e/0x1d0 ? sockfd_lookup_light+0x1a/0x170 __sys_sendmsg+0xd2/0x180 ? __sys_sendmsg_sock+0x20/0x20 ? volver a adquirir bloqueos retenidos+0x4d0/0x4d0 ? debug_smp_processor_id+0x17/0x20 __x64_sys_sendmsg+0x72/0xb0 ? lockdep_hardirqs_on+0x7d/0x100 x64_sys_call+0x894/0x9f0 do_syscall_64+0x64/0x130 entrada_SYSCALL_64_after_ ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2024-56636)
Severidad: MEDIA
Fecha de publicación: 27/12/2024
Fecha de última actualización: 08/10/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: geneve: no suponga que el encabezado mac está configurado en geneve_xmit_skb() No debemos asumir que el encabezado mac está configurado en la ruta de salida. Utilice skb_eth_hdr() en lugar de eth_hdr() para solucionar el problema. sysbot informó lo siguiente: ADVERTENCIA: CPU: 0 PID: 11635 en include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [en línea] ADVERTENCIA: CPU: 0 PID: 11635 en include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [en línea] ADVERTENCIA: CPU: 0 PID: 11635 en include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [en línea] ADVERTENCIA: CPU: 0 PID: 11635 en include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Módulos vinculados en: CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 No contaminado 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [en línea] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [en línea] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [en línea] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039 Código: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ff RSP: 0018:ffffc90003b2f870 EFLAGS: 00010283 RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000 RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003 RBP: ffffc90003b2f9f0 R08: 000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 000000000000002 R12: ffff88806603c000 R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23 FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: __netdev_start_xmit include/linux/netdevice.h:5002 [en línea] netdev_start_xmit include/linux/netdevice.h:5011 [en línea] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [en línea] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [en línea] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [en línea] __sock_sendmsg net/socket.c:726 [en línea] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [en línea] __se_sys_sendto net/socket.c:2200 [en línea] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] hacer_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f
Vulnerabilidad en ONNX 1.17.0 (CVE-2025-51480)
Severidad: ALTA
Fecha de publicación: 22/07/2025
Fecha de última actualización: 08/10/2025
La vulnerabilidad de Path Traversal en onnx.external_data_helper.save_external_data en ONNX 1.17.0 permite a los atacantes sobrescribir archivos arbitrarios al proporcionar rutas external_data.location creadas que contienen secuencias de recorrido, eludiendo las restricciones de directorio previstas.