Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> bpf: Corrige condición de carrera en devmap en PREEMPT_RT<br /> <br /> En kernels PREEMPT_RT, la xdp_dev_bulk_queue (bq) por CPU puede ser accedida concurrentemente por múltiples tareas preemptivas en la misma CPU.<br /> <br /> El código original asume que bq_enqueue() y __dev_flush() se ejecutan atómicamente con respecto la una a la otra en la misma CPU, confiando en local_bh_disable() para prevenir la expropiación. Sin embargo, en PREEMPT_RT, local_bh_disable() solo llama a migrate_disable() (cuando PREEMPT_RT_NEEDS_BH_LOCK no está configurado) y no deshabilita la expropiación, lo que permite que la planificación CFS expropie una tarea durante bq_xmit_all(), permitiendo que otra tarea en la misma CPU entre en bq_enqueue() y opere en la misma bq por CPU concurrentemente.<br /> <br /> Esto lleva a varias condiciones de carrera:<br /> <br /> 1. Doble liberación / uso después de liberación en bq-&amp;gt;q[]: bq_xmit_all() toma una instantánea de cnt = bq-&amp;gt;count, luego itera bq-&amp;gt;q[0..cnt-1] para transmitir tramas. Si es expropiada después de la instantánea, una segunda tarea puede llamar a bq_enqueue() -&amp;gt; bq_xmit_all() en la misma bq, transmitiendo (y liberando) las mismas tramas. Cuando la primera tarea se reanuda, opera con punteros obsoletos en bq-&amp;gt;q[], causando uso después de liberación.<br /> <br /> 2. Corrupción de bq-&amp;gt;count y bq-&amp;gt;q[]: bq_enqueue() concurrente modificando bq-&amp;gt;count y bq-&amp;gt;q[] mientras bq_xmit_all() los está leyendo.<br /> <br /> 3. Condición de carrera de desmontaje de dev_rx/xdp_prog: __dev_flush() borra bq-&amp;gt;dev_rx y bq-&amp;gt;xdp_prog después de bq_xmit_all(). Si es expropiada entre el retorno de bq_xmit_all() y bq-&amp;gt;dev_rx = NULL, una bq_enqueue() expropiadora ve dev_rx aún configurado (no-NULL), omite añadir bq a la flush_list, y encola una trama. Cuando __dev_flush() se reanuda, borra dev_rx y elimina bq de la flush_list, dejando huérfana la trama recién encolada.<br /> <br /> 4. __list_del_clearprev() en flush_node: similar a la condición de carrera de cpumap, ambas tareas pueden llamar a __list_del_clearprev() en el mismo flush_node, la segunda desreferencia el puntero prev ya establecido en NULL.<br /> <br /> La condición de carrera entre la tarea A (__dev_flush -&amp;gt; bq_xmit_all) y la tarea B (bq_enqueue -&amp;gt; bq_xmit_all) en la misma CPU:<br /> <br /> Tarea A (xdp_do_flush) Tarea B (redirección ndo_xdp_xmit)<br /> ---------------------- --------------------------------<br /> __dev_flush(flush_list)<br /> bq_xmit_all(bq)<br /> cnt = bq-&amp;gt;count /* ej. 16 */<br /> /* comienza a iterar bq-&amp;gt;q[] */<br /> &amp;lt;-- CFS expropia la Tarea A --&amp;gt;<br /> bq_enqueue(dev, xdpf)<br /> bq-&amp;gt;count == DEV_MAP_BULK_SIZE<br /> bq_xmit_all(bq, 0)<br /> cnt = bq-&amp;gt;count /* ¡los mismos 16! */<br /> ndo_xdp_xmit(bq-&amp;gt;q[])<br /> /* tramas liberadas por el controlador */<br /> bq-&amp;gt;count = 0<br /> &amp;lt;-- La Tarea A se reanuda --&amp;gt;<br /> ndo_xdp_xmit(bq-&amp;gt;q[])<br /> /* uso después de liberación: ¡tramas ya liberadas! */<br /> <br /> Solucione esto añadiendo un local_lock_t a xdp_dev_bulk_queue y adquiriéndolo en bq_enqueue() y __dev_flush(). Estas rutas ya se ejecutan bajo local_bh_disable(), así que use local_lock_nested_bh() que en no-RT es una anotación pura sin sobrecarga, y en PREEMPT_RT proporciona un bloqueo de suspensión por CPU que serializa el acceso a la bq.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: target: Corrección de bloqueo recursivo en __configfs_open_file()<br /> <br /> En flush_write_buffer, se adquiere &amp;amp;p-&amp;gt;frag_sem y luego se llama a la función de almacenamiento cargada, que, aquí, es target_core_item_dbroot_store(). Esta función llamó a filp_open(), tras lo cual se llamaron a estas funciones (en orden inverso), según el rastro de llamadas:<br /> <br /> down_read<br /> __configfs_open_file<br /> do_dentry_open<br /> vfs_open<br /> do_open<br /> path_openat<br /> do_filp_open<br /> file_open_name<br /> filp_open<br /> target_core_item_dbroot_store<br /> flush_write_buffer<br /> configfs_write_iter<br /> <br /> target_core_item_dbroot_store() intenta validar la nueva ruta de archivo intentando abrir la ruta de archivo que se le proporcionó; sin embargo, en este caso, el informe de error muestra:<br /> <br /> db_root: not a directory: /sys/kernel/config/target/dbroot<br /> <br /> indicando que se intentó abrir el mismo archivo configfs, en el que está trabajando actualmente. Así, está intentando adquirir el semáforo frag_sem del mismo archivo del que ya posee el semáforo obtenido en flush_write_buffer(), lo que lleva a adquirir el semáforo de forma anidada y una posibilidad de bloqueo recursivo.<br /> <br /> Solucione esto modificando target_core_item_dbroot_store() para usar kern_path() en lugar de filp_open() para evitar abrir el archivo usando la función específica del sistema de archivos __configfs_open_file(), y modificándolo aún más para hacer que esta corrección sea compatible.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> accel/amdxdna: Solución para el interbloqueo en suspensión y reanudación<br /> <br /> Cuando una aplicación emite una consulta IOCTL mientras la suspensión automática está en ejecución, puede producirse un interbloqueo. La ruta de consulta mantiene dev_lock y luego llama a pm_runtime_resume_and_get(), que espera a que la suspensión en curso finalice. Mientras tanto, la devolución de llamada de suspensión intenta adquirir dev_lock y se bloquea, lo que resulta en un interbloqueo.<br /> <br /> Esto se soluciona liberando dev_lock antes de llamar a pm_runtime_resume_and_get() y volviéndolo a adquirir después de que la llamada finalice. También se adquiere dev_lock en la devolución de llamada de reanudación para mantener la consistencia del bloqueo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: pegasus: validar puntos finales USB<br /> <br /> El controlador pegasus debería validar que el dispositivo que está sondeando tiene el número y tipos adecuados de puntos finales USB que espera antes de que se vincule a él. Si un dispositivo malicioso no tuviera los mismos urbs, el controlador fallará más tarde cuando acceda ciegamente a estos puntos finales.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> nfc: pn533: soltar correctamente la referencia de la interfaz USB al desconectarse<br /> <br /> Cuando el dispositivo se desconecta del controlador, hay un contador de referencias &amp;#39;colgante&amp;#39; en la interfaz USB que fue obtenida en la función de devolución de llamada de sondeo. Solucionar esto soltando correctamente la referencia después de que hayamos terminado con ella.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: vxlan: corrige la desreferencia de puntero NULL de nd_tbl cuando IPv6 está deshabilitado<br /> <br /> Al arrancar con el parámetro &amp;#39;ipv6.disable=1&amp;#39;, nd_tbl nunca se inicializa porque inet6_init() sale antes de que se llame a ndisc_init(), que es la función que lo inicializa. Si se inyecta un paquete IPv6 en la interfaz, se llama a route_shortcircuit() y ocurre una desreferencia de puntero NULL en neigh_lookup().<br /> <br /> BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000380<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> [...]<br /> RIP: 0010:neigh_lookup+0x20/0x270<br /> [...]<br /> Traza de Llamadas:<br /> <br /> vxlan_xmit+0x638/0x1ef0 [vxlan]<br /> dev_hard_start_xmit+0x9e/0x2e0<br /> __dev_queue_xmit+0xbee/0x14e0<br /> packet_sendmsg+0x116f/0x1930<br /> __sys_sendto+0x1f5/0x200<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x12f/0x1590<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Esto se corrige añadiendo una verificación temprana en route_shortcircuit() cuando el protocolo es ETH_P_IPV6. Tenga en cuenta que ipv6_mod_enabled() no se puede usar aquí porque VXLAN puede estar integrado incluso cuando IPv6 se compila como un módulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> scsi: core: Corrección de fuga de contador de referencias para tagset_refcnt<br /> <br /> Esta fuga causará un cuelgue al desmontar el host SCSI. Por ejemplo,<br /> iscsid se cuelga con el siguiente rastreo de llamadas:<br /> <br /> [130120.652718] scsi_alloc_sdev: Fallo de asignación durante el escaneo SCSI, algunos dispositivos SCSI podrían no estar configurados<br /> <br /> PID: 2528 TAREA: ffff9d0408974e00 CPU: 3 COMANDO: iscsid<br /> #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4<br /> #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f<br /> #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0<br /> #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f<br /> #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b<br /> #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp]<br /> #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi]<br /> #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi]<br /> #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6<br /> #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> accel/amdxdna: Corrección de memset fuera de límites en el manejo de ranuras de comando<br /> <br /> El espacio restante en una ranura de comando puede ser menor que el tamaño del encabezado de comando. Borrar el encabezado de comando con memset() antes de verificar el espacio de ranura disponible puede resultar en una escritura fuera de límites y corrupción de memoria.<br /> <br /> Esto se corrige moviendo la llamada a memset() después de la validación del tamaño.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: ethernet: mtk_eth_soc: Restablecer puntero de programa a old_prog en caso de error en mtk_xdp_setup()<br /> <br /> Restablecer puntero de programa eBPF a old_prog y no disminuir su contador de referencias si la rutina mtk_open en mtk_xdp_setup() falla.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drbd: corrección de desreferencia de puntero nulo en error de lectura local<br /> <br /> En drbd_request_endio(), READ_COMPLETED_WITH_ERROR se pasa a __req_mod() con un peer_device NULO:<br /> <br /> __req_mod(req, what, NULL, &amp;amp;m);<br /> <br /> El gestor de READ_COMPLETED_WITH_ERROR luego pasa incondicionalmente este peer_device NULO a drbd_set_out_of_sync(), que lo desreferencia, causando una desreferencia de puntero nulo.<br /> <br /> Esto se corrige obteniendo el peer_device a través de first_peer_device(device), coincidiendo con cómo drbd_req_destroy() maneja la misma situación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> irqchip/sifive-plic: Solución para la interrupción congelada debido a la configuración de afinidad<br /> <br /> PLIC ignora el mensaje de finalización de interrupción para interrupciones deshabilitadas, explicado por la especificación:<br /> <br /> El PLIC señala que ha completado la ejecución de un gestor de interrupciones escribiendo el ID de interrupción que recibió de la solicitud en el registro de solicitud/finalización. El PLIC no verifica si el ID de finalización es el mismo que el último ID de solicitud para ese objetivo. Si el ID de finalización no coincide con una fuente de interrupción que está actualmente habilitada para el objetivo, la finalización es ignorada silenciosamente.<br /> <br /> Esto causó problemas en el pasado, porque una interrupción puede ser deshabilitada mientras aún está siendo gestionada y plic_irq_eoi() no tenía efecto. Eso se solucionó verificando si la interrupción está deshabilitada, y si es así, habilitarla, antes de enviar el mensaje de finalización. Esa verificación se realiza con irqd_irq_disabled().<br /> <br /> Sin embargo, eso no es suficiente porque el bit de habilitación para el hart de gestión puede ser cero a pesar de que irqd_irq_disabled(d) sea falso. Esto puede ocurrir cuando la configuración de afinidad se cambia mientras un hart todavía está gestionando la interrupción.<br /> <br /> Este problema es fácilmente reproducible volcando un archivo grande a la uart (lo que genera muchas interrupciones) y al mismo tiempo seguir cambiando la configuración de afinidad de la interrupción de la uart. El puerto de la uart se congela casi instantáneamente.<br /> <br /> Solucione esto verificando el bit de habilitación del PLIC en lugar de irqd_irq_disabled().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> atm: lec: corrige desreferencia de puntero nulo en lec_arp_clear_vccs<br /> <br /> syzkaller reportó una desreferencia de puntero nulo en lec_arp_clear_vccs().<br /> Este problema puede ser fácilmente reproducido usando el reproductor de syzkaller.<br /> <br /> En el módulo ATM LANE (Emulación de LAN), el mismo atm_vcc puede ser compartido por múltiples entradas de lec_arp_table (por ejemplo, a través de entry-&amp;gt;vcc o entry-&amp;gt;recv_vcc).<br /> Cuando el VCC subyacente se cierra, lec_vcc_close() itera sobre todas las entradas ARP y llama a lec_arp_clear_vccs() para cada entrada coincidente.<br /> <br /> Por ejemplo, cuando lec_vcc_close() itera a través de las hlists en priv-&amp;gt;lec_arp_empty_ones u otras tablas ARP:<br /> <br /> 1. En la primera iteración, para la primera entrada ARP coincidente que comparte el VCC, lec_arp_clear_vccs() libera el vpriv asociado (que es vcc-&amp;gt;user_back) y establece vcc-&amp;gt;user_back en NULL.<br /> 2. En la segunda iteración, para la siguiente entrada ARP coincidente que comparte el mismo VCC, lec_arp_clear_vccs() es llamada de nuevo. Obtiene un vpriv NULL de vcc-&amp;gt;user_back (a través de LEC_VCC_PRIV(vcc)) y luego intenta desreferenciarlo a través de &amp;#39;vcc-&amp;gt;pop = vpriv-&amp;gt;old_pop&amp;#39;, lo que lleva a un fallo por desreferencia de puntero nulo.<br /> <br /> Soluciona esto añadiendo una comprobación de nulos para vpriv antes de desreferenciarlo. Si vpriv ya es NULL, significa que el VCC ha sido limpiado por una llamada anterior, por lo que podemos omitir de forma segura la limpieza y simplemente limpiar los punteros vcc/recv_vcc de la entrada.<br /> <br /> El bloque de limpieza completo (incluyendo vcc_release_async()) se coloca dentro de la guarda de vpriv porque un vpriv NULL indica que el VCC ya ha sido completamente liberado por una iteración anterior — repetir el desmontaje establecería banderas de forma redundante y activaría retrollamadas en un socket que ya se está cerrando.<br /> <br /> La etiqueta Fixes apunta al commit inicial porque la ruta entry-&amp;gt;vcc ha sido vulnerable desde el código original. La ruta entry-&amp;gt;recv_vcc fue añadida posteriormente por el commit 8d9f73c0ad2f (&amp;#39;atm: fix a memory leak of vcc-&amp;gt;user_back&amp;#39;) con el mismo patrón, y ambas rutas se corrigen aquí.