Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perro guardián: solucione el posible use after free llamando a del_timer_sync(). La ruta de eliminación de este controlador llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: corrige un Oops en pnfs_mark_request_commit() al hacer O_DIRECT. Corrige una condición de Oopsable en pnfs_mark_request_commit() cuando colocamos un conjunto de escrituras en la lista de confirmación para reprogramarlas después de un Intento fallido de pNFS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: watchdog: sc520_wdt: corrige posible use after free en wdt_turnoff(). La ruta de eliminación de este módulo llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perro guardián: soluciona el posible use after free en wdt_startup(). La ruta de eliminación de este módulo llama a del_timer(). Sin embargo, esa función no espera hasta que finalice el controlador del temporizador. Esto significa que es posible que el controlador del temporizador aún esté ejecutándose después de que haya finalizado la función de eliminación del controlador, lo que daría como resultado un use after free. Para solucionarlo, llame a del_timer_sync(), lo que garantiza que el controlador del temporizador haya finalizado y no pueda reprogramarse.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/arm-smmu: corrige la fuga de recuento de referencias de arm_smmu_device en la traducción de direcciones. El problema de recuento de referencias ocurre en varias rutas de manejo de excepciones de arm_smmu_iova_to_phys_hard(). Cuando ocurren esos escenarios de error, la función se olvida de disminuir el recuento de "smmu" aumentado en arm_smmu_rpm_get(), lo que provoca una fuga de recuento. Solucione este problema saltando a la etiqueta "out" cuando se produzcan esos escenarios de error.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/signal: detecta y previene un desbordamiento de la pila de señales alternativa. El kernel envía contexto a la pila del espacio de usuario para prepararse para el controlador de señales del usuario. Cuando el usuario ha proporcionado una pila de señales alternativa, a través de sigaltstack(2), es fácil para el núcleo verificar que el tamaño de la pila es suficiente para el contexto de hardware actual. Compruebe si escribir el contexto de hardware en la pila alternativa excederá su tamaño. En caso afirmativo, en lugar de corromper los datos del usuario y continuar con el controlador de señal original, se entrega una señal SIGSEGV inmediata. Refactorice el código de verificación del puntero de la pila desde on_sig_stack() y use el nuevo asistente. Si bien el kernel permite que el nuevo código fuente descubra y utilice un tamaño de pila de señales alternativo suficiente, esta verificación sigue siendo necesaria para proteger los archivos binarios con un tamaño de pila de señales alternativo insuficiente contra la corrupción de datos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu: corrige la fuga de refcount de arm_smmu_device cuando falla arm_smmu_rpm_get arm_smmu_rpm_get() invoca pm_runtime_get_sync(), lo que aumenta el refcount de "smmu" aunque el valor de retorno sea menor que 0. El problema del conteo de referencias ocurre en algunas rutas de manejo de errores de arm_smmu_rpm_get() en sus funciones de llamada. Cuando arm_smmu_rpm_get() falla, las funciones de la persona que llama se olvidan de disminuir el recuento de "smmu" aumentado en arm_smmu_rpm_get(), lo que provoca una fuga de recuento. Solucione este problema llamando a pm_runtime_resume_and_get() en lugar de pm_runtime_get_sync() en arm_smmu_rpm_get(), lo que puede mantener el recuento equilibrado en caso de fallo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: iscsi: corrige el uso de la conexión después de liberarla durante los reinicios. Si no hemos realizado una llamada de destino de desvinculación, podemos correr donde iscsi_conn_teardown activa el subproceso EH y luego libera la conexión mientras esos Los hilos todavía están accediendo a la conexión ehwait. Solo podemos hacer un TMF por sesión, por lo que esto simplemente mueve los campos TMF de la conexión a la sesión. Luego podemos confiar en la llamada iscsi_session_teardown->iscsi_remove_session->__iscsi_unbind_session para eliminar el objetivo y sus dispositivos, y saber después de ese punto que no hay ningún dispositivo o llamada scsi-ml intentando acceder a la sesión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: megaraid_sas: corrige la fuga de recursos en caso de fallo de la sonda El controlador no limpia todos los recursos asignados correctamente cuando la función scsi_add_host(), megasas_start_aen() falla durante el dispositivo PCI Investigacion. Limpia todos esos recursos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: serial: 8250: serial_cs: corrige una pérdida de memoria en la ruta de manejo de errores. En la función de sonda, si el 'serial_config()' final falla, se está perdiendo 'info'. Agregue una ruta de manejo de recursos para liberar esta memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: realiza un seguimiento correcto de los descriptores de poke del subprog y corrige el use-after-free. Los subprogramas llaman a map_poke_track(), pero en el lanzamiento del programa no hay ningún enlace para llamar a map_poke_untrack(). Sin embargo, al lanzar el programa, la memoria auxiliar (y la tabla de descriptores de inserción) se liberan aunque todavía tengamos una referencia a ella en la lista de elementos de los datos auxiliares del mapa. Cuando ejecutamos map_poke_run(), terminamos accediendo a la memoria liberada, lo que activa KASAN en prog_array_map_poke_run(): [...] [402.824689] ERROR: KASAN: use-after-free en prog_array_map_poke_run+0xc2/0x34e [402.824698] Lectura del tamaño 4 en la dirección ffff8881905a7940 mediante la tarea hubble-fgs/4337 [402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Contaminado: GI 5.12.0+ #399 [402.824715] Seguimiento de llamadas: [402.824719] x93/ 0xc2 [402.824727] print_address_description.constprop.0+0x1a/0x140 [402.824736]? prog_array_map_poke_run+0xc2/0x34e [402.824740]? prog_array_map_poke_run+0xc2/0x34e [ 402.824744] kasan_report.cold+0x7c/0xd8 [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e [ 402.824757] prog_array_map_poke_run+0xc2/0x34e [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0 [...] Los elementos en cuestión se recorren de la siguiente manera: for (i = 0; i < elem-> aux->tamaño_poke_tab; i++) { empujar = &elem->aux->poke_tab[i]; [...] El acceso a size_poke_tab es una lectura de 4 bytes, verificada verificando las compensaciones en el volcado de KASAN: [402.825004] La dirección con errores pertenece al objeto en ffff8881905a7800 que pertenece al caché kmalloc-1k de tamaño 1024 [402.825008] La dirección con errores se encuentra a 320 bytes dentro de una región de 1024 bytes [ffff8881905a7800, ffff8881905a7c00) La salida de error de bpf_prog_aux: struct bpf_prog_aux { [...] /* --- límite de cacheline 5 (320 bytes) --- */ u32 tamaño_poke_tab; /* 320 4 */ [...] En general, los subprogramas no necesariamente gestionan sus propias estructuras de datos. Por ejemplo, BTF func_info y linfo son sólo punteros a la estructura principal del programa. Esto permite realizar un recuento de referencias y una sanitización de estos últimos, lo que simplifica un poco su gestión. La estructura aux->poke_tab, sin embargo, no siguió esta lógica. La solución inicial propuesta para este error de use-after-free incorporó aún más el seguimiento de datos de inserción en el subprograma con un recuento de referencias adecuado. Sin embargo, Daniel y Alexei se preguntaron por qué tratábamos a estos objetos de manera especial; Estoy de acuerdo, es innecesario. La solución aquí elimina la asignación de la tabla de poke por subprograma y el seguimiento del mapa y, en su lugar, simplemente apunta el puntero aux->poke_tab a la tabla de poke del programa principal. De esta manera, el seguimiento de mapas se simplifica al programa principal y no necesitamos gestionarlos por subprograma. Esto también significa que bpf_prog_free_deferred(), que desenrolla el recuento de referencias del programa y libera objetos, debe garantizar que no intentemos liberar dos veces el poke_tab al liberar las estructuras de subprog. Esto se resuelve fácilmente haciendo NULL en el puntero poke_tab. El segundo detalle es garantizar que la lógica JIT por subprograma solo realice correcciones en las entradas poke_tab[] que posee. Para hacer esto, agregamos un puntero en la estructura poke para señalar el valor del subprograma para que los JIT puedan verificar fácilmente mientras recorren la estructura poke_tab si la entrada actual pertenece al programa actual. El puntero auxiliar es estable y, por tanto, adecuado para dicha comparación. ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige tcp_init_transfer() para no restablecer icsk_ca_initialized Esta confirmación corrige un error (encontrado por syzkaller) que podría causar dobles inicializaciones falsas para los módulos de control de congestión, lo que podría causar pérdidas de memoria o Otros problemas para los módulos de control de congestión (como CDG) que asignan memoria en sus funciones de inicio. El escenario con errores construido por syzkaller era algo así como: (1) crear un socket TCP (2) iniciar una conexión TFO a través de sendto() (3) mientras el socket está en TCP_SYN_SENT, llamar a setsockopt(TCP_CONGESTION), que llama a: tcp_set_congestion_control() - > tcp_reinit_congestion_control() -> tcp_init_congestion_control() (4) recibe ACK, se establece la conexión, llama a tcp_init_transfer(), establece icsk_ca_initialized=0 (sin llamar primero a cc->release()), llama a tcp_init_congestion_control() nuevamente. Tenga en cuenta que en esta secuencia tcp_init_congestion_control() se llama dos veces sin una llamada cc->release() en el medio. Por lo tanto, para los módulos CC que asignan memoria en su función init(), por ejemplo, CDG, puede ocurrir una pérdida de memoria. La herramienta syzkaller logró encontrar un reproductor que desencadenó dicha filtración en CDG. El error se introdujo cuando la confirmación 8919a9b31eb4 ("tcp: solo inicia el control de congestión si aún no está inicializado") introdujo icsk_ca_initialized y estableció icsk_ca_initialized en 0 en tcp_init_transfer(), perdiendo la posibilidad de una secuencia como la anterior, donde un proceso podría llamar setsockopt(TCP_CONGESTION) en el estado TCP_SYN_SENT (es decir, después de connect() o TFO open sendmsg()), que llamaría a tcp_init_congestion_control(). No tenía la intención de restablecer ninguna inicialización que el usuario ya hubiera realizado explícitamente; simplemente perdió la posibilidad de esa secuencia particular (que Syzkaller logró encontrar).