Vulnerabilidades

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido declarada crítica. Esta vulnerabilidad afecta a la función formQuickIndex del archivo /goform/QuickIndex. La manipulación del argumento PPPOEPassword provoca un desbordamiento de búfer en la región stack de la memoria. El ataque se puede iniciar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-261142 es el identificador asignado a esta vulnerabilidad. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: soluciona el fallo del kernel cuando se recibe 1588 en dispositivos HIP08 Los dispositivos HIP08 no registran los dispositivos ptp, por lo que hdev->ptp es NULL, pero el hardware puede recibir 1588 y configure el bit HNS3_RXD_TS_VLD_B, por lo que, si coincide con este caso, el acceso a hdev->ptp->flags provocará una falla del kernel: [5888.946472] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000018 [5888.946475] No se puede para manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000018 ... [ 5889.266118 ] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 ge] [5889.279101] sp: ffff800012c3bc50 [5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24 : ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [5889.340965] x11: bbfeff4d22000000 x10: 00000000000000000 [5889.347303] x9: ffff8000094021 24 x8: 0200f78811dfbb4d [5889.353637] x7: 2200000000191b01 x6: FFFF208002A7D480 [5889.359959] x5: 000000000000000000 X4: 0000000000000000 [5889.366271] x3: 0000000000000000 X2: 00000000000000000000000000000000000000000000000000 ABRIBA 80 [5889.378857] Lista de llamada: [5889.382285] HCLGE_PTP_GET_RX_HWTS+0x40/0x170 [HCLGE] [5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 0] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] 0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.46071 7] cpu_startup_entry+0x30/0xfc [ 5889.465523] second_start_kernel+0x158/0x1ec [ 5889.470936] Código: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [5889.477950] SMP: deteniendo las CPU secundarias [5890.514626] SMP: no se pudieron detener las CPU secundarias 0-69,71-95 [5890.522951] Iniciando el kernel de crashdump...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ip_tunnel: asegúrese de extraer el encabezado interno en ip_tunnel_rcv(). Aplique la misma solución que las encontradas en: 8d975c15c0cd ("ip6_tunnel: asegúrese de extraer el encabezado interno en __ip6_tnl_rcv() ") 1ca1ba465e55 ("geneve: asegúrese de extraer el encabezado interno en geneve_rx()") Tenemos que guardar skb->network_header en una variable temporal para poder volver a calcular el puntero network_header después de una llamada a pskb_inet_may_pull(). pskb_inet_may_pull() se asegura de que los encabezados necesarios estén en skb->head. syzbot informó: ERROR: KMSAN: valor uninit en __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea] ERROR: KMSAN: valor uninit en INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] ERROR: KMSAN: uninit -valor en IP_ECN_decapsulate include/net/inet_ecn.h:302 [en línea] ERROR: KMSAN: valor uninit en ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [en línea ] INET_ECN_decapsulate include/net/inet_ecn.h:275 [en línea] IP_ECN_decapsulate include/net/inet_ecn.h:302 [en línea] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [en línea] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/ 0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [en línea] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c: 254 dst_input include/net/dst.h:461 [en línea] ip_rcv_finish net/ipv4/ip_input.c:449 [en línea] NF_HOOK include/linux/netfilter.h:314 [en línea] ip_rcv+0x46f/0x760 net/ipv4/ip_input .c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [en línea] neto /core/dev.c:5793 tun_rx_batched+0x3ee/0x980 controladores/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 controladores/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 controladores/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs /read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf /0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+ 0x1be /0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [en línea] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [en línea] new_sync_write fs/read_write.c:497 [en línea] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [en línea] __se_sys_write fs/read_write.c:652 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch /x86 /entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la verificación de desbordamiento del mapa de pila en arcos de 32 bits. El código del mapa de pila se basa en roundup_pow_of_two() para calcular el número de depósitos de hash y contiene una verificación de desbordamiento verificando si el valor resultante es 0. Sin embargo, en arcos de 32 bits, el código de resumen en sí puede desbordarse al realizar un desplazamiento hacia la izquierda de 32 bits de un valor largo sin signo, lo cual es un comportamiento indefinido, por lo que no se garantiza que se trunque claramente. Esto fue activado por syzbot en el tipo DEVMAP_HASH, que contiene la misma verificación, copiada del código hashtab. La confirmación en la etiqueta de correcciones en realidad intentó solucionar este problema, pero la corrección no tuvo en cuenta la UB, por lo que la corrección solo funciona en CPU donde un desbordamiento resulta en un truncamiento claro a cero, lo cual no está garantizado. Verificar el valor antes de redondear no tiene este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la comprobación de desbordamiento de hashtab en arcos de 32 bits. El código hashtab se basa en roundup_pow_of_two() para calcular el número de depósitos de hash y contiene una comprobación de desbordamiento comprobando si el valor resultante es 0. Sin embargo, en arcos de 32 bits, el código de resumen en sí puede desbordarse al realizar un desplazamiento hacia la izquierda de 32 bits de un valor largo sin signo, lo cual es un comportamiento indefinido, por lo que no se garantiza que se trunque claramente. Esto fue activado por syzbot en el tipo DEVMAP_HASH, que contiene la misma verificación, copiada del código hashtab. Así que aplique la misma solución a hashtab, moviendo la verificación de desbordamiento antes del resumen.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige la verificación de desbordamiento de DEVMAP_HASH en arcos de 32 bits. El código devmap asigna un número de depósitos de hash igual a la siguiente potencia de dos del valor max_entries proporcionado al crear el mapa. Al redondear a la siguiente potencia de dos, la variable de 32 bits que almacena el número de depósitos puede desbordarse, y el código verifica el desbordamiento comprobando si el valor truncado de 32 bits es igual a 0. Sin embargo, en arcos de 32 bits el redondeo hacia arriba puede desbordarse a mitad de camino, porque termina haciendo un desplazamiento hacia la izquierda de 32 bits en un valor largo sin signo. Si el tamaño de un largo sin firmar es de cuatro bytes, este es un comportamiento indefinido, por lo que no hay garantía de que terminemos con un valor 0 agradable y ordenado al final. Syzbot logró convertir esto en un bloqueo en arm32 creando un DEVMAP_HASH con max_entries > 0x80000000 y luego intentando actualizarlo. Solucione este problema moviendo la verificación de desbordamiento antes de la operación de redondeo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: af_bluetooth: Reparar interbloqueo Intentar ejecutar sock_lock en .recvmsg puede causar un interbloqueo como se muestra a continuación, por lo que en lugar de usar sock_sock, usa sk_receive_queue.lock en bt_sock_ioctl para evitar el UAF: INFORMACIÓN: tarea kworker/u9:1:121 bloqueada durante más de 30 segundos. No contaminado 6.7.6-lemon #183 Cola de trabajo: hci0 hci_rx_work Seguimiento de llamadas: __schedule+0x37d/0xa00 Schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270? terminar_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 proceso_one_work+0x13a/0x2f0 trabajador_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: btusb: corrige la pérdida de memoria. Esto verifica si CONFIG_DEV_COREDUMP está habilitado antes de intentar clonar el skb y también se asegura de que btmtk_process_coredump libere el skb pasado siguiendo la misma lógica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: msft: Reparar pérdida de memoria Reparar pérdida de búfer asignado para enviar MSFT_OP_LE_MONITOR_ADVERTISEMENT.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_core: soluciona un posible desbordamiento del búfer struct hci_dev_info tiene un campo de nombre de tamaño fijo[8], por lo que en caso de que hdev->name sea mayor que strcpy intentaría escribir más allá su tamaño, por lo que esto soluciona este problema cambiando al uso de strscpy.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: Bluetooth: btrtl: arreglar acceso a memoria fuera de los límites El problema es detectado por KASAN. El controlador btrtl utiliza datos privados de hci para almacenar 'struct btrealtek_data'. Si se utiliza el controlador btrtl con btusb, entonces la memoria para los datos privados de hci se asigna en btusb. Pero no se asignan datos privados después de hci_dev, cuando se usa btrtl con hci_h5. Esta confirmación agrega asignación de memoria para el caso hci_h5. ==================================================== ================ ERROR: KASAN: losa fuera de los límites en btrtl_initialize+0x6cc/0x958 [btrtl] Escritura de tamaño 8 en la dirección ffff00000f5a5748 por tarea kworker/u9:0 /76 Nombre del hardware: Pine64 PinePhone (1.2) (DT) Cola de trabajo: hci0 hci_power_on [bluetooth] Rastreo de llamadas: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8 + 0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] abierto+0x34/0x90 [bluetooth] hci_power_on+0xc4/ 0x3c8 [bluetooth] Process_one_work+0x328/0x6f0 trabajador_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Asignado por tarea 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 _alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc +0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0realmente_probe+0x254/ 0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+ 0x88/0x158 async_run_entry_fn+0xd0/0x388 Process_one_work+0x328/0x6f0 trabajador_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x3c/0x68 san_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work +0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [ hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf +0xac/0x178 Flush_to_ldisc+0x130/0x2c8 Process_one_work+0x328/0x6f0 trabajador_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Penúltima creación de trabajo potencialmente relacionado: kasan_save_stack+0x3c/0x68 _record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14 /0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] arriba+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [ hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] Process_one_work+0x328/0x6f0 trabajador_thread+0x 410/0x778 kthread+0x168/0x178 ret_from_fork +0x10/0x20 ================================================ =====================

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/vt-d: no emitir solicitud de invalidación de ATS cuando el dispositivo está desconectado. Para aquellos dispositivos terminales que se conectan al sistema a través de puertos con capacidad de conexión en caliente, los usuarios pueden solicitar un reinicio en caliente del dispositivo. Al agitar el enlace del dispositivo configurando el registro de control de enlace de la ranura, como respuesta de secuencia de interrupción DLLSC pciehp_ist(), pciehp descargará el controlador del dispositivo y luego lo apagará. por lo tanto, causa una solicitud de invalidación de TLB de dispositivo IOMMU (especificación Intel VT-d o invalidación ATS en especificación PCIe r6.1) para que se envíe un dispositivo de destino inexistente y un bucle mortal para reintentar esa solicitud después de que se active una falla de ITE en el contexto de interrupción. Eso provocaría la siguiente advertencia continua de bloqueo duro y el sistema se bloquearía [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] Vigilancia NMI: Vigilancia detectó BLOQUEO duro en la CPU 144 [ 4223.822622 ] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: cargado Contaminado: versión del kernel GS OE xxxx [ 4223.822623] Nombre del hardware: nombre del proveedor xxxx 666-106 , BIOS 01.01.02.03.01 15/05/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Código: 48 be 00 00 00 00 00 08 00 00 49 85 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP : 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 00000000000000014 RCX: 0000000000000005 [ 4223.822625] : ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 00000000000000000 [4223.822626] R10: 0000000000000010 R11 : 000000000000000018 R12: FFFF9F384005E200 [4223.822626] R13: 000000000000000004 R14: 00000000000000000046 0000) KNLGS: 000000000000000000 [4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4223.822627] CR2: 00007ffe86515d80 CR3: 000002FD3000A001 CR4: 0000000000770EE0 [4223.8222627] DR0: 000000000000000000000000 00000000 DR6: 000000000000FFFE07F0 DR7: 000000000000000400 [4223.822628] PKRU: 555555554 [4223.822628] Lista de llamada: [4223.822628 ] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] _device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain +0x60/0x90 [ 4223.822630] dispositivo_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631 ] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176 /0x180 [4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [4223.822632]? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Pánico del kernel - no se sincroniza: BLOQUEO duro [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: cargado Contaminado: versión del kernel GS OE xxxx [ 4223.822634] Nombre del hardware: nombre del proveedor xxxx 666-106, BIOS 01.01.02.03.01 15/05/2023 [ 4223.822634] Seguimiento de llamadas: [ 4223.822634] [ 4223.822635] dump_stack+0x6d/0x88 [ 42 23.822635] pánico+0x101/ 0x2d0 [4223.822635]? ret_from_fork+0x11/0x30 [ 4223.822635] nmi_panic.cold.14+0xc/0xc [ 4223.822636] ---truncado---