Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: think-lmi: corregir fuga de referencia Si se encuentra un atributo duplicado usando kset_find_obj(), se devuelve una referencia a ese atributo que debe eliminarse en consecuencia usando kobject_put( ). Mueva la validación del nombre de la configuración a una función separada para permitir este cambio sin tener que duplicar el código de limpieza para esta configuración. Como nota al margen, se solucionó un error muy similar en el commit 7295a996fdab ("plataforma/x86: dell-sysman: corregir fuga de referencia"), por lo que parece que el error se copió de ese controlador. Compilación probada únicamente.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: soluciona el posible desgarro del almacén en neigh_periodic_work() Mientras miraba un informe de syzbot relacionado que involucraba a neigh_periodic_work(), descubrí que olvidé agregar una anotación al eliminar un elemento protegido por RCU de una lista. Los lectores usan rcu_deference(*np), necesitamos usar rcu_assign_pointer() o WRITE_ONCE() en el lado del escritor para evitar que la tienda se rompa. Utilizo rcu_assign_pointer() para tener soporte lockdep, esta fue la elección hecha en neigh_flush_dev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: rechaza las redirecciones de salida de sk_msg a sockets que no son TCP. Con un mapa SOCKMAP/SOCKHASH y un programa sk_msg, el usuario puede dirigir los mensajes enviados desde un socket TCP (s1) para que realmente salgan desde otro socket TCP (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT caso tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_ app_limited(s2) // espera tcp_sock tcp_sendmsg_locked(s2 ) // ídem Hay una suposición codificada en la cadena de llamadas de que el socket de salida (s2) es un socket TCP. Sin embargo, en el commit 122e6c79efe1 ("sock_map: Actualizar comprobaciones de tipo de calcetín para UDP") hemos habilitado redirecciones a sockets que no son TCP. Esto se hizo por el bien de los programas BPF sk_skb. No había ninguna sangría para admitir el caso de uso de envío a salida de sk_msg. Como resultado, los intentos de envío a salida a través de un socket que no es TCP provocan un bloqueo debido a una conversión no válida de sock a tcp_sock: ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000002f... Seguimiento de llamadas: . mostrar_regs+0x60/0x70? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160? do_user_addr_fault+0x2d7/0x800? rcu_is_watching+0x11/0x50? exc_page_fault+0x70/0x1c0? asm_exc_page_fault+0x27/0x30? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60? __this_cpu_preempt_check+0x13/0x20? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Rechace la selección de sockets que no sean TCP como destino de redireccionamiento desde un programa BPF sk_msg para evitar el bloqueo. Cuando lo intente, el usuario recibirá un error EACCES de la llamada al sistema send/sendto/sendmsg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: nfc: llcp: Agregar bloqueo al modificar la lista de dispositivos La lista de dispositivos necesita mantener su bloqueo asociado al modificarla, o la lista podría corromperse, como descubrió syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: corrige la condición de verificación de oob en mwifiex_process_rx_packet Solo omita la ruta del código al intentar acceder a los encabezados rfc1042 cuando el búfer sea demasiado pequeño, para que el controlador aún pueda procesar paquetes sin encabezados rfc1042 .

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: erofs: corrige la pérdida de memoria de la deduplicación comprimida global LZMA Al estresar las imágenes microLZMA EROFS con la nueva función de deduplicación comprimida global habilitada (`-Ededupe`), encontré algunas páginas temporales de corta duración no se publicaron correctamente, lo que podría causar OOM inesperados horas más tarde. Solucionémoslo ahora (LZ4 y DEFLATE no tienen este problema).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4, ipv6: se corrigió el manejo de transhdrlen en __ip{,6}_append_data() Incluir el transhdrlen en longitud es un problema cuando el paquete está parcialmente lleno (por ejemplo, algo como enviar(MSG_MORE ) sucedió anteriormente) al agregarlo a un paquete IPv4 o IPv6, ya que no queremos repetir el encabezado de transporte ni contabilizarlo dos veces. Esto puede suceder en algunas circunstancias, como al realizar un empalme en un zócalo L2TP. El síntoma observado es una advertencia en __ip6_append_data(): ADVERTENCIA: CPU: 1 PID: 5042 en net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 que ocurre cuando MSG_SPLICE_PAGES se utiliza para agregar más datos a un skbuff que ya está parcialmente ocupado. La advertencia se produce cuando 'copiar' es mayor que la cantidad de datos en el iterador del mensaje. Esto se debe a que la longitud solicitada incluye la longitud del encabezado de transporte cuando no debería hacerlo. Esto puede desencadenarse, por ejemplo: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); enlazar(sfd, ...); // ::1 conectar(sfd, ...); // ::1 puerto 7 enviar(sfd, buffer, 4100, MSG_MORE); enviar archivo (sfd, dfd, NULL, 1024); Solucione este problema agregando solo transhdrlen a la longitud si la cola de escritura está vacía en l2tp_ip6_sendmsg(), de manera análoga a cómo hace las cosas UDP. Parece que l2tp_ip_sendmsg() no sufrirá este problema ya que construye el paquete UDP por sí mismo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: usb: smsc75xx: corrigió el acceso a valores uninit en __smsc75xx_read_reg syzbot informó el siguiente problema de acceso a valores uninit: =============== ====================================== ERROR: KMSAN: valor uninit en controladores smsc75xx_wait_ready/net /usb/smsc75xx.c:975 [en línea] ERROR: KMSAN: valor uninit en smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 No contaminado 5.8.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x21c/ 0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [en línea ] smsc75xx_bind+0x5c9/0x11e0 controladores/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 controladores/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 controladores/usb/core/driver.c:374 very_probe +0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/ bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 dispositivo_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/base/bus.c:491 dispositivo_add+0x3b0e /0x40d0 controladores/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 controladores/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 controladores/usb/core/generic.c:241 usb_probe_device+0x311/0x490 controladores/ usb/core/driver.c:272 Actually_probe+0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c: 807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 device_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/ base/bus.c:491 dispositivos_add+0x3b0e/0x40d0 controladores/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 controladores/usb/core/hub.c:2554 hub_port_connect controladores/usb/core/hub.c:5208 [ en línea] hub_port_connect_change drivers/usb/core/hub.c:5348 [en línea] port_event drivers/usb/core/hub.c:5494 [en línea] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 Process_one_work+ 0x1688/0x2140 kernel/workqueue.c:2269 trabajador_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Variable local ----buf.i87@smsc75xx_bind creada en: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 drivers /net/usb/smsc75xx.c:1482 __smsc75xx_read_reg controladores/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready controladores/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 controladores/net/usb /smsc75xx.c:1482 Este problema se debe a que usbnet_read_cmd() lee menos bytes de los solicitados (cero bytes en el reproductor). En este caso, 'buf' no se completa correctamente. Este parche soluciona el problema devolviendo -ENODATA si usbnet_read_cmd() lee menos bytes de los solicitados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: sony: solucione una posible pérdida de memoria en sony_probe() Si se produce un error después de una llamada exitosa a usb_alloc_urb(), se debe llamar a usb_free_urb().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un problema de corrupción de memoria Unas pocas líneas arriba, se kzalloc()'ed espacio para: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof (struct ieee80211_rate) 'mvm->nvm_data' es una 'struct iwl_nvm_data', por lo que está bien. Al final de esta estructura, se encuentra la matriz flexible de 'canales'. Cada elemento es de tipo 'struct ieee80211_channel'. Entonces solo se asigna 1 elemento en esta matriz. Al hacer: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; Apuntamos al primer elemento de la matriz flexible 'canales'. Entonces esto está bien. Sin embargo, al hacer: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); debido a la conversión "(u8 *)", agregamos solo 1 a la dirección del comienzo de la matriz flexible. Es probable que queramos apuntar a la 'estructura ieee80211_rate' asignada justo después. Retire la fundición espuria para que la aritmética del puntero funcione como se esperaba.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mana: corrige el manejo de errores de TX CQE Para un tipo de error de TX CQE desconocido (probablemente de un hardware más nuevo), aún libere el SKB, actualice la cola de cola, etc.; de lo contrario, la contabilidad estará equivocada. Además, los errores de TX pueden desencadenarse al inyectar paquetes corruptos, así que reemplace WARN_ONCE para registrar errores con velocidad limitada.