Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/xen: agregue alguna verificación de puntero nulo a smp.c kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free Una serie reciente de DRM que pretende simplificar el soporte para "puentes transparentes" y el manejo de aplazamientos de sonda expuso irónicamente un uso posterior -Problema gratuito en el aplazamiento de la sonda pmic_glink_altmode. Esto se ha manifestado como que el subsistema de visualización ocasionalmente falla al inicializarse y se eliminan las referencias del puntero NULL durante el arranque de máquinas como la Lenovo ThinkPad X13s. Específicamente, el puente dp-hpd actualmente está registrado antes de que se hayan adquirido todos los recursos, lo que significa que también se puede cancelar su registro en caso de aplazamientos de sonda. Mientras tanto, hay una ventana de carrera donde el nuevo controlador del puente auxiliar (o el controlador PHY anteriormente) puede haber buscado el puente dp-hpd y almacenado un puntero (sin recuento de referencias) al puente que está a punto de ser desasignado. Cuando el controlador de pantalla se inicializa posteriormente, esto activa un use-after-free al conectar los puentes: dp -> aux -> dp-hpd (liberado) que puede, por ejemplo, provocar que el puente liberado no se pueda conectar: [drm :drm_bridge_attach [drm]] *ERROR* no se pudo adjuntar el puente /soc@0/phy@88eb000 al codificador TMDS-31: -16 o una desreferencia de puntero NULL: no se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000000... Seguimiento de llamadas: drm_bridge_attach+0x70/0x1a8 [drm] drm_aux_bridge_attach+0x24/0x38 [aux_bridge] drm_bridge_attach+0x80/0x1a8 [drm] dp_bridge_init+0xa8/0x15c [msm] msm_dp_modeset_init+0x28/0xc4 [msm] El puente DRM la implementación es claramente frágil e implícitamente construido sobre el supuesto de que es posible que los puentes nunca desaparezcan. En este caso, la solución es mover el registro del puente en el controlador pmic_glink_altmode después de que se hayan buscado todos los recursos. Por cierto, con la nueva implementación del puente dp-hpd, que registra dispositivos secundarios, esto también es un requisito debido a un problema de larga data en el núcleo del controlador que, de lo contrario, puede provocar un bucle de aplazamiento de la sonda (consulte el compromiso fbc35b45f9f6 ("Agregar documentación sobre el significado de -EPROBE_DEFER")). [DB: mensaje de confirmación ligeramente corregido agregando la palabra 'compromiso']

Se encontró una vulnerabilidad en Tenda AC500 2.0.1.9(1307). Ha sido clasificada como crítica. Esto afecta a la función R7WebsSecurityHandler del archivo /goform/execCommand. La manipulación del argumento contraseña provoca un desbordamiento de búfer en la región stack de la memoria. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-261141. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

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.