Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: power: Supply: rk817: reparar la fuga de recuento de nodos Dan Carpenter informa que la advertencia del verificador estático Smatch encontró que hay otra fuga de recuento en la función de sonda. Si bien of_node_put() se agregó en una de las rutas de retorno, de hecho debería agregarse para TODAS las rutas de retorno que devuelven un error y en el momento de eliminar el controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: soluciona el uso potencial después de liberar en nilfs_gccache_submit_read_data() En nilfs_gccache_submit_read_data(), se llama a brelse(bh) para eliminar el recuento de referencias de bh cuando falla la llamada a nilfs_dat_translate(). Si el recuento de referencias llega a 0 y la página del propietario se desbloquea, es posible que bh quede liberado. Sin embargo, se elimina la referencia a bh->b_page para colocar la página después de eso, lo que puede provocar un error de Use After Free. Este parche mueve la operación de lanzamiento después de desbloquear y poner la página. NOTA: La función en cuestión solo se llama en GC y, en combinación con las herramientas actuales del usuario, la traducción de direcciones usando DAT no ocurre en esa función, por lo que la ruta del código que causa este problema no se ejecutará. Sin embargo, es posible ejecutar esa ruta de código modificando intencionalmente la librería GC del área de usuario o llamando directamente al GC ioctl. [konishi.ryusuke@gmail.com: NOTA agregada al registro de confirmación]

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: cifs: Reparar UAF en cifs_demultiplex_thread() Hay un UAF cuando xfstests en cifs: ERROR: KASAN: use-after-free en smb2_is_network_name_deleted+0x27/0x160 Lectura de tamaño 4 en addr ffff888810103fc08 por tarea cifsd/923 cpu: 1 pid: 923 com: cifsd no contaminado 6.1.0-rc4+ #45 ... llamar a la llamada: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_raport+0xad/0x130 kasan_range_range_range_range_range_range_mad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xy 0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Asignado por la tarea 923: kasan_save_stack+0x1e/ 0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc +0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Liberado por tarea 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info +0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf 0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount +0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 Entry_SYSCALL_64_after_hwframe+0x46/0 xb0 La UAF es porque: mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------ ------------------- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compuesto_send_recv | smb_send_rqst | esperar_para_respuesta | esperar_event_state [1] | | recepción_estándar3 | cifs_handle_standard | manejar_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] MATAR el proceso [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_eliminado [6] | devolución de llamada 1. Después de enviar la solicitud al servidor, espere la respuesta hasta mid->mid_state != ENVIADO; 2. Reciba la respuesta del servidor y configúrelo en medio; 3. Establezca el estado medio en RECIBIDO; 4. Finalice el proceso, el estado medio ya RECIBIDO, obtenga 0; 5. Manejar y liberar la respuesta de negociación; 6. UAF. Se puede reproducir fácilmente agregando algo de retraso en [3] - [6]. Solo la llamada de sincronización tiene el problema ya que la devolución de llamada de la llamada asíncrona se ejecuta en el proceso cifsd. Agregue un estado adicional para marcar el estado medio como LISTO antes de despertar al camarero, luego podrá obtener la respuesta de manera segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: elimina BUG() después de no poder insertar un elemento de índice de directorio retrasado. En lugar de llamar a BUG() cuando no logramos insertar un elemento de índice de directorio retrasado en el árbol del nodo retrasado, podemos simplemente libere todos los recursos que hemos asignado/adquirido antes y devuelva el error a la persona que llama. Esto está bien porque todas las cadenas de llamadas existentes deshacen todo lo que hayan hecho antes de llamar a btrfs_insert_delayed_dir_index() o BUG_ON (al crear instantáneas pendientes en la ruta de confirmación de la transacción). Así que elimine la llamada BUG() y realice un manejo adecuado de los errores. Esto se relaciona con un informe de syzbot vinculado a continuación, pero no lo soluciona porque solo evita que se produzca un ERROR (), no soluciona el problema por el cual de alguna manera intentamos usar el doble del mismo número de índice para diferentes elementos de índice.

*** 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 resolvió la siguiente vulnerabilidad: Revertir "tty: n_gsm: fix UAF in gsm_cleanup_mux" Esto revierte el commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. el commit anterior se revierte porque no resolvió el problema original. gsm_cleanup_mux() intenta liberar los ttys virtuales llamando a gsm_dlci_release() para cada DLCI disponible. Allí, se llama a dlci_put() para disminuir el contador de referencia para el DLCI a través de tty_port_put() que finalmente llama a gsm_dlci_free(). Esto ya borra el puntero que se está verificando en gsm_cleanup_mux() antes de llamar a gsm_dlci_release(). Por lo tanto, no es necesario borrar este puntero en gsm_cleanup_mux() como se hizo en el commit revertida. el commit introduce una desreferencia de puntero nulo: ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420? search_exception_tables+0x37/0x50? fixup_exception+0x21/0x310? exc_page_fault+0x69/0x150? asm_exc_page_fault+0x26/0x30? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm] release_one_tty+0x37/0xe0 proceso_one_work+0x1e6/0x3e0 trabajador_thread+0x4c/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 El problema real es que nada protege a dlci_put() de ser llamado varias veces mientras el controlador tty se activó pero aún no terminó de llamar a gsm_dlci_free().

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: HID: intel-ish-hid: ipc: Deshabilita y vuelve a habilitar el bit ACPI GPE Las plataformas basadas en EHL (Elkhart Lake) proporcionan un servicio OOB (Fuera de banda), que permite despertar dispositivo cuando el sistema está en S5 (estado Soft-Off). Este servicio OOB se puede habilitar/deshabilitar desde la configuración del BIOS. Cuando está habilitado, el dispositivo ISH obtiene la capacidad de activación PME. Para habilitar la activación de PME, el controlador también debe habilitar el bit ACPI GPE. Al reanudar, el BIOS borrará el bit de activación. Por lo tanto, el controlador debe volver a habilitarlo en la función de reanudación para mantener la siguiente capacidad de activación. Pero esta limpieza del bit de activación del BIOS no disminuye el recuento de referencias GPE del sistema operativo interno, por lo que esta reactivación en cada reanudación provocará que el recuento de referencias se desborde. Entonces, primero deshabilite y vuelva a habilitar el bit ACPI GPE usando acpi_disable_gpe().

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 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.