Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrección de puntero nulo en skb_segment_list. El commit 3a1296a38d0c ("net: Compatibilidad con encadenamiento de fraglist GRO/GSO") introdujo GRO con lista UDP. La segmentación depende de que frag_list permanezca intacto al pasar por la pila de red. Esta suposición puede fallar a veces, ya que frag_list se arrastra al área lineal, dejando frag_list como nulo. Cuando esto sucede, puede desencadenar la consiguiente desreferencia de puntero nulo y generar un pánico en el kernel. Revertir la condición de prueba debería solucionarlo. [19185.577801][ C1] ERROR: desreferencia de puntero NULL del núcleo, dirección: ... [19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390 ... [19185.834644][ C1] Rastreo de llamadas: [19185.841730][ C1] [19185.848563][ C1] __udp_gso_segment+0x33e/0x510 [19185.857370][ C1] inet_gso_segment+0x15b/0x3e0 [19185.866059][ C1] skb_mac_gso_segment+0x97/0x110 [19185.874939][ C1] __skb_gso_segment+0xb2/0x160 [19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0 [19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90 [19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200 [19185.910003][ C1] ip_local_deliver_finish+0x44/0x60 [19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0 [19185.927834][ C1] registro_de_proceso+0x88/0x130 [19185.935840][ C1] __napi_poll+0x27/0x150 [19185.943447][ C1] acción_de_rx_net+0x27e/0x5f0 [19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core] [19185.960848][ C1] __do_softirq+0xbc/0x25d [19185.968607][ C1] irq_exit_rcu+0x83/0xb0 [19185.976247][ C1] common_interrupt+0x43/0xa0 [19185.984235][ C1] asm_common_interrupt+0x22/0x40 ... [19186.094106][ C1]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/i8259: Marcar interrupciones PIC heredadas con IRQ_LEVEL. Baoquan informó que, tras desencadenar un fallo, el kernel posterior al fallo no arranca aproximadamente la mitad de las veces. Esto desencadena una desreferencia de puntero NULL en el código de tick periódico. Esto sucede porque la interrupción del temporizador heredada (IRQ0) se reenvía por software, lo que ocurre en el contexto de una interrupción suave (tasklet). En este contexto, get_irq_regs() devuelve NULL, lo que provoca la desreferencia de puntero NULL. El motivo del reenvío es una interrupción APIC espuria en el vector IRQ0, que se captura y provoca un reenvío cuando se habilita la interrupción del temporizador heredada. Esto es incorrecto porque las interrupciones PIC heredadas se activan por nivel y, por lo tanto, nunca deberían reenviarse por software; sin embargo, nada activa el indicador IRQ_LEVEL en esas interrupciones, por lo que el código principal desconoce su tipo de activación. Asegúrese de que IRQ_LEVEL esté activado al configurar las interrupciones PCI heredadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Comprueba si hay algún tcp_bpf_prots al clonar un oyente Un socket que escucha vinculado a un sockmap tiene su sk_prot anulado. Apunta a una de las variantes de struct proto en tcp_bpf_prots. La variante depende de la familia del socket y de los programas sockmap que estén adjuntos. Un socket hijo clonado de un oyente TCP hereda inicialmente su sk_prot. Pero antes de que finalice la clonación, restauramos el proto del hijo al original del oyente que no es tcp_bpf_prots. Esto sucede en tcp_create_openreq_child -> tcp_bpf_clone. Hoy, en tcp_bpf_clone detectamos si el proto del hijo debe restaurarse comprobando solo la variante del proto TCP_BPF_BASE. Esto no es correcto. El sk_prot del socket de escucha vinculado a un mapa de socks puede apuntar a cualquier variante de tcp_bpf_prots. Si el sk_prot del socket de escucha no es la variante TCP_BPF_BASE, el socket hijo se abandona involuntariamente si el sk_prot heredado por tcp_bpf_clone lo impide. Esto genera problemas como la recursión infinita al cerrar [1], ya que el estado del hijo no está configurado para su uso con operaciones de tcp_bpf_prot. Ajuste la comprobación en tcp_bpf_clone para detectar todas las variantes de tcp_bpf_prots. Tenga en cuenta que no sería suficiente comprobar el estado del socket al sobrescribir el sk_prot en tcp_bpf_update_proto para usar siempre la variante TCP_BPF_BASE para los sockets de escucha. Desde el commit b8b8315e39ff ("bpf, sockmap: eliminar el controlador unhash para el uso de sockmap BPF"), es posible que un socket pase al estado TCP_LISTEN mientras ya está vinculado a un sockmap, por ejemplo, connect() -> insert into map -> connect(AF_UNSPEC) -> listen(). [1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: dts: imx8mm-verdin: No apague eth-phy Actualmente, si se suspende utilizando el estado de congelación o de memoria, el controlador fec intenta apagar el phy, lo que provoca un bloqueo del kernel y un kernel no responsable con el siguiente seguimiento de llamada: [ 24.839889 ] Seguimiento de llamada: [ 24.839892 ] phy_error+0x18/0x60 [ 24.839898 ] kszphy_handle_interrupt+0x6c/0x80 [ 24.839903 ] phy_interrupt+0x20/0x2c [ 24.839909 ] irq_thread_fn+0x30/0xa0 [ 24.839919 ] irq_thread+0x178/0x2c0 [ 24.839925 ] kthread+0x154/0x160 [ 24.839932 ] ret_from_fork+0x10/0x20 Dado que actualmente no hay ninguna funcionalidad en el subsistema phy para apagar phys, deshabilitemos la función de apagar el phy Ethernet.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fscache: utilice wait_on_bit() para esperar la liberación del volumen cedido. La liberación del volumen cedido activará la adquisición de volumen pendiente mediante wake_up_bit(), sin embargo no coincide con wait_var_event() utilizado en fscache_wait_on_volume_collision() y nunca activará al que espera en la cola de espera porque estas dos funciones operan en colas de espera diferentes. Según la implementación en fscache_wait_on_volume_collision(), si la activación de una adquisición pendiente se demora más de 20 segundos (por ejemplo, debido a la demora en el cierre del fd a pedido), el primer wait_var_event_timeout() expirará y el siguiente wait_var_event() se colgará para siempre como se muestra a continuación: FS-Cache: Potencial colisión de volumen nuevo=00000024 antiguo=00000022 ...... INFORMACIÓN: montaje de tarea: 1148 bloqueado durante más de 122 segundos. No contaminado 6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: __schedule+0x2f6/0xb80 schedule+0x67/0xe0 fscache_wait_on_volume_collision.cold+0x80/0x82 __fscache_acquire_volume+0x40d/0x4e0 erofs_fscache_register_volume+0x51/0xe0 [erofs] erofs_fscache_register_fs+0x19c/0x240 [erofs] erofs_fc_fill_super+0x746/0xaf0 [erofs] vfs_get_super+0x7d/0x100 get_tree_nodev+0x16/0x20 erofs_fc_get_tree+0x20/0x30 [erofs] vfs_get_tree+0x24/0xb0 path_mount+0x2fa/0xa90 do_mount+0x7c/0xa0 __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Considering that wake_up_bit() es más selectivo, corríjalo utilizando wait_on_bit() en lugar de wait_var_event() para esperar la liberación del volumen cedido. Además, debido a que waitqueue_active() se usa en wake_up_bit() y clear_bit() no implica ninguna barrera de memoria, use clear_and_wake_up_bit() para agregar la barrera de memoria faltante entre cursor->flags y waitqueue_active().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: Arreglar el conteo de referencias de solicitud durante la captura de errores y el volcado de debugfs Cuando se agregó soporte para GuC a la captura de errores, el conteo de referencias alrededor del objeto de solicitud se rompió. Arréglenlo. La búsqueda basada en contexto administra el bloqueo de giro alrededor de la búsqueda internamente. Por lo tanto, también necesita obtener el conteo de referencias internamente. La búsqueda basada en solicitud solo de execlist se basa en el bloqueo externo, por lo que necesita un conteo de referencias externo pero dentro del bloqueo de giro, no fuera de él. El único otro llamador de la búsqueda basada en contexto es el código para volcar el estado del motor a debugfs. Ese código anteriormente no obtenía una referencia explícita en absoluto, ya que hace todo mientras mantiene el bloqueo de giro específico de execlist. Por lo tanto, eso necesita actualizarse, ya que el bloqueo de giro no ayuda cuando se usa el envío de GuC. En lugar de intentar obtener/poner condicionalmente dependiendo del modelo de envío, simplemente cámbielo para que siempre haga obtener/poner. v2: Documentar explícitamente agregar una línea en blanco adicional en algún código denso (Andy Shevchenko). Se corrigen varias posibles desreferencias de puntero nulo en caso de no encontrarse ninguna solicitud (algunas detectadas por Tvrtko, ¡pero había más!). También se corrigen una solicitud filtrada en caso de !started y otra en __guc_reset_context, ahora que intel_context_find_active_request cuenta las referencias de la solicitud devuelta. v3: Se añade el sufijo _get a intel_context_find_active_request ahora que obtiene una referencia (Daniele). v4: Se divide el cambio de intel_guc_find_hung_context en un parche independiente y se cambia el nombre de intel_context_find_active_request_get a intel_context_get_active_request (Tvrtko). v5: s/locking/reference counting/ en el mensaje de confirmación (Tvrtko) (seleccionado del commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: ublk: extensión de queue_size para corregir el desbordamiento Al validar el borrador del objetivo ublk de SPDK, en un caso en el que se asigna una gran profundidad de cola al dispositivo ublk de múltiples colas, el objetivo ublk se ejecutaría en un estado incorrecto extraño. Durante las rondas de revisión y depuración, se encontró un error de desbordamiento en el controlador ublk. En ublk_cmd.h, UBLK_MAX_QUEUE_DEPTH es 4096, lo que significa que cada profundidad de cola ublk se puede configurar tan grande como 4096. Pero al configurar qd para un dispositivo ublk, sizeof(struct ublk_queue) + profundidad * sizeof(struct ublk_io) será mayor que 65535 si qd es mayor que 2728. Entonces queue_size se desborda y ublk_get_queue() hace referencia a una posición de puntero incorrecta. El contenido incorrecto de los elementos ublk_queue provocará un acceso a memoria fuera de los límites. Extienda queue_size en ublk_device como "unsigned int".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: squashfs: endurecimiento de la comprobación de seguridad en squashfs_read_xattr_id_table. Al montar un sistema de archivos dañado, un entero con signo '*xattr_ids' puede ser menor que cero. Esto provoca el cálculo incorrecto de los valores de 'len' e 'indexes', lo que puede causar un valor nulo de referencia de referencia (ptr) en copy_bio_to_actor() o accesos fuera de límites en las siguientes comprobaciones de seguridad dentro de squashfs_read_xattr_id_table(). Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con Syzkaller.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: dp83822: Se corrige el acceso a puntero nulo en dispositivos DP83825/DP83826. La función probe() solo se utiliza para la estructura física (PHY) DP83822, lo que deja el puntero de datos privados sin inicializar para los modelos DP83825/26 más pequeños. Si bien todos los usos de la estructura de datos privados están ocultos en las devoluciones de llamada específicas de 82822, la configuración de la interrupción se comparte entre todos los modelos. Esto provoca una desreferencia de puntero nulo en las estructuras físicas (PHY) más pequeñas, ya que accede a los datos privados sin verificar. Verificar el puntero evita esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block, bfq: corrección de uaf para bfqq en bic_set_bfqq(). Después del commit 64dc8c732f5c ("block, bfq: corrección de posible uaf para 'bfqq->bic'"), se accederá a bic->bfqq en bic_set_bfqq(). Sin embargo, en algunos contextos, se liberará bic->bfqq y se llamará a bic_set_bfqq() con el bic->bfqq liberado. Para solucionar el problema, libere siempre bfqq después de bic_set_bfqq().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: Corrección de una comprobación incorrecta en update_parent_subparts_cpumask(). Se detectó que la comprobación para ver si una partición podía usar todas las CPU del conjunto de CPU principal en update_parent_subparts_cpumask() era incorrecta. Como resultado, es posible dejar la partición principal sin CPU efectiva, incluso si hay tareas en el conjunto de CPU principal. Esto puede provocar un pánico del sistema, como se informa en [1]. Corrija este problema actualizando la comprobación para que falle al habilitar la partición si el valor de CPU efectivas de la partición principal es un subconjunto del valor de CPU permitidas de la partición secundaria. También registre el código de error cuando se produce un error en update_prstate() y agregue un caso de prueba donde la partición principal y la secundaria tengan la misma lista de CPU y la partición principal tenga una tarea. En este caso, la habilitación de la partición en la secundaria fallará. [1] https://www.spinics.net/lists/cgroups/msg36254.html

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: dividir el temporizador de transmisión en transmisión y tiempo de espera El temporizador para la transmisión de PDU isotp anteriormente tenía dos funciones: 1. enviar dos tramas consecutivas con un intervalo de tiempo determinado 2. supervisar los tiempos de espera para las tramas de control de flujo y las tramas de eco Esto llevó a comprobaciones de txstate más grandes y potencialmente a un problema descubierto por syzbot que habilitó la característica panic_on_warn durante las pruebas. La antigua función 'txtimer' se divide en 'txfrtimer' y 'txtimer' para manejar las dos funcionalidades anteriores con devoluciones de llamadas de temporizador independientes. Los dos temporizadores simplificados ahora se ejecutan en modo de una sola vez y hacen que las transiciones de estado (especialmente con isotp_rcv_echo) sean mejor comprensibles.