Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64/fpsimd: señal: Corrección de la restauración del contexto SVE Cuando SME es compatible, la restauración del contexto de señal SVE puede salir mal de varias maneras, incluyendo colocar la tarea en un estado inválido donde el kernel puede leer de memoria fuera de límites (y puede potencialmente sufrir una falla fatal) y/o puede terminar la tarea con un SIGKILL. (1) Restaurar un contexto con SVE_SIG_FLAG_SM establecido puede colocar la tarea en un estado inválido donde SVCR.SM está establecido (y sve_state no es NULL) pero TIF_SME está despejado, lo que consecuentemente resulta en lecturas de memoria fuera de límites y/o la terminación de la tarea con SIGKILL. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde el contexto de señal SVE ha sido modificado por el espacio de usuario o fue guardado en el contexto de otra tarea (p. ej., como con CRIU), ya que de lo contrario la presencia de un contexto de señal SVE con SVE_SIG_FLAG_SM implica que TIF_SME ya está establecido. Mientras en este estado, task_fpsimd_load() NO configurará SMCR_ELx (dejando algún valor arbitrario configurado en hardware) antes de restaurar SVCR e intentar restaurar los registros SVE en modo streaming desde la memoria a través de sve_load_state(). Como el valor de SMCR_ELx.LEN puede ser mayor que la longitud del vector SVE en modo streaming de la tarea, esto puede leer memoria fuera del sve_state asignado a la tarea, leyendo datos no relacionados y/o desencadenando una falla. Si bien esto puede resultar en la carga de secretos en los registros SVE en modo streaming, estos valores nunca son expuestos. Como TIF_SME está despejado, fpsimd_bind_task_to_cpu() configurará CPACR_ELx.SMEN para atrapar accesos EL0 a los registros SVE en modo streaming, por lo que estos no pueden ser accedidos directamente en EL0. Como fpsimd_save_user_state() verifica la longitud del vector en vivo antes de guardar el estado (S)SVE en memoria, ningún valor secreto puede ser guardado de nuevo en memoria (y por lo tanto no puede ser observado a través de ptrace, señales, etc.). Cuando la longitud del vector en vivo no coincide con la longitud del vector esperada para la tarea, fpsimd_save_user_state() enviará una señal SIGKILL fatal a la tarea. Por lo tanto, la tarea puede ser terminada después de ejecutar el espacio de usuario por algún período de tiempo. (2) Restaurar un contexto con SVE_SIG_FLAG_SM despejado no despeja el SVCR.SM de la tarea. Si SVCR.SM estaba establecido antes de restaurar el contexto, entonces la tarea quedará en modo streaming inesperadamente, y algún estado de registro se combinará de manera inconsistente, aunque la tarea quedará en un estado legítimo desde el punto de vista del kernel. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde ptrace ha sido usado para establecer SVCR.SM después de la entrada a la llamada al sistema sigreturn, ya que la entrada a la llamada al sistema despeja SVCR.SM. En estos casos, los datos de registro SVE proporcionados se cargarán en el sve_state de la tarea usando la longitud del vector SVE no-streaming y los registros FPSIMD se fusionarán en esto usando la longitud del vector SVE en modo streaming. Solución para (1) estableciendo TIF_SME al establecer SVCR.SM. Esto también requiere asegurar que el sme_state de la tarea ha sido asignado, pero como esto podría contener estado ZA en vivo, no debe ser puesto a cero. Solución para (2) despejando SVCR.SM al restaurar un contexto de señal SVE con SVE_SIG_FLAG_SM despejado. Para consistencia, he adelantado la manipulación de SVCR, TIF_SVE, TIF_SME y fp_type, inmediatamente después de la asignación de sve_state/sme_state, antes de la restauración del estado de registro real. Esto facilita asegurar que estos siempre se modifiquen de manera consist

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipvlan: Hacer que el addrs_lock sea por puerto<br /> <br /> Hacer que el addrs_lock sea por puerto, no por dispositivo ipvlan.<br /> <br /> El código inicial parece estar escrito bajo la suposición de que cualquier cambio de dirección debe ocurrir bajo RTNL. Pero no es así para el caso de IPv6. Así que<br /> <br /> 1) Introducir addrs_lock por puerto.<br /> <br /> 2) Fue necesario corregir lugares donde se olvidó tomar el bloqueo (ipvlan_open/ipvlan_close)<br /> <br /> Esto parece ser un problema muy menor, sin embargo. Ya que es muy poco probable que ipvlan_add_addr() sea llamado en 2 CPU simultáneamente. Pero, sin embargo, esto podría causar:<br /> <br /> 1) Falso negativo de ipvlan_addr_busy(): una interfaz iteró a través de todos los port-&amp;gt;ipvlans + ipvlan-&amp;gt;addrs bajo algún spinlock de ipvlan, y otra añadió IP bajo su propio bloqueo. Aunque esto solo es posible para IPv6, ya que parece que solo ipvlan_addr6_event() puede ser llamado sin rtnl_lock.<br /> <br /> 2) Condición de carrera ya que ipvlan_ht_addr_add(port) es llamado bajo diferentes bloqueos ipvlan-&amp;gt;addrs_lock.<br /> <br /> Esto no debería afectar el rendimiento, ya que añadir/eliminar IP es una situación rara y el spinlock no se toma en rutas rápidas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: corrige el rastreo de llamadas de recarga de devlink<br /> <br /> El commit 4da71a77fc3b (&amp;#39;ice: read internal temperature sensor&amp;#39;) introdujo la lectura del sensor de temperatura interno a través de HWMON. ice_hwmon_init() se añadió a ice_init_feature() y ice_hwmon_exit() se añadió a ice_remove(). Como resultado, si se utiliza la recarga de devlink para reinicializar el dispositivo y luego se elimina el controlador, puede ocurrir un rastreo de llamadas.<br /> <br /> ERROR: no se puede manejar el fallo de página para la dirección: ffffffffc0fd4b5d<br /> Rastreo de Llamadas:<br /> string+0x48/0xe0<br /> vsnprintf+0x1f9/0x650<br /> sprintf+0x62/0x80<br /> name_show+0x1f/0x30<br /> dev_attr_show+0x19/0x60<br /> <br /> El rastreo de llamadas se repite aproximadamente cada 10 minutos cuando las herramientas de monitoreo del sistema (p. ej., sadc) intentan leer los atributos huérfanos de hwmon sysfs que referencian memoria de módulo liberada.<br /> <br /> La secuencia es:<br /> 1. Carga del controlador, ice_hwmon_init() es llamado desde ice_init_feature()<br /> 2. Recarga de Devlink hacia abajo, el flujo no llama a ice_remove()<br /> 3. Recarga de Devlink hacia arriba, ice_hwmon_init() es llamado desde ice_init_feature() resultando en una segunda instancia<br /> 4. Descarga del controlador, ice_hwmon_exit() llamado desde ice_remove() dejando la primera instancia de hwmon huérfana con un puntero colgante<br /> <br /> Solucione esto moviendo ice_hwmon_exit() de ice_remove() a ice_deinit_features() para asegurar una simetría de limpieza adecuada con ice_hwmon_init().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: qfq: Usar cl_is_active para determinar si la clase está activa en qfq_rm_from_ag<br /> <br /> Esto es más bien un parche preventivo para hacer el código más consistente y para prevenir posibles exploits que emplean manipulaciones de qlen secundarias en qfq.<br /> usar cl_is_active en lugar de depender del qlen del qdisc secundario para determinar la activación de la clase.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gestión del tiempo: Ajustar el estado de salto para el gestor de tiempo auxiliar correcto<br /> <br /> Cuando se introdujo __do_ajdtimex() para manejar adjtimex para cualquier gestor de tiempo, esta referencia a tk_core no fue actualizada. Cuando se invocaba en un gestor de tiempo auxiliar, el gestor de tiempo principal se actualizaría incorrectamente.<br /> <br /> Esto es detectado por los diagnósticos de depuración de bloqueos porque el bloqueo de secuencia de los gestores de tiempo se escribe sin mantener su spinlock asociado:<br /> <br /> ADVERTENCIA: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125<br /> aux_clock_adj (kernel/time/timekeeping.c:2979)<br /> __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)<br /> <br /> Actualizar el gestor de tiempo auxiliar correcto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> arm64/fpsimd: señal: Asignar almacenamiento SSVE al restaurar ZA<br /> <br /> El código para restaurar un contexto ZA no intenta asignar el sve_state de la tarea antes de establecer TIF_SME. En consecuencia, restaurar un contexto ZA puede colocar una tarea en un estado inválido donde TIF_SME está establecido pero el sve_state de la tarea es NULL.<br /> <br /> En casos legítimos pero poco comunes donde el contexto de señal ZA NO fue creado por el kernel en el contexto de la misma tarea (por ejemplo, si la tarea se guarda/restaura con algo como CRIU), no tenemos garantía de que sve_state se haya asignado previamente. En estos casos, el espacio de usuario puede entrar en modo de transmisión sin atrapar mientras sve_state es NULL, causando una desreferencia de puntero NULL posterior cuando el kernel intenta almacenar el estado del registro:<br /> <br /> | # ./sigreturn-za<br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | Mem abort info:<br /> | ESR = 0x0000000096000046<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x06: level 2 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> | CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00<br /> | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000<br /> | Internal error: Oops: 0000000096000046 [#1] SMP<br /> | Modules linked in:<br /> | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> | pc : sve_save_state+0x4/0xf0<br /> | lr : fpsimd_save_user_state+0xb0/0x1c0<br /> | sp : ffff80008070bcc0<br /> | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658<br /> | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40<br /> | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000<br /> | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c<br /> | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020<br /> | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0<br /> | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48<br /> | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000<br /> | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440<br /> | Call trace:<br /> | sve_save_state+0x4/0xf0 (P)<br /> | fpsimd_thread_switch+0x48/0x198<br /> | __switch_to+0x20/0x1c0<br /> | __schedule+0x36c/0xce0<br /> | schedule+0x34/0x11c<br /> | exit_to_user_mode_loop+0x124/0x188<br /> | el0_interrupt+0xc8/0xd8<br /> | __el0_irq_handler_common+0x18/0x24<br /> | el0t_64_irq_handler+0x10/0x1c<br /> | el0t_64_irq+0x198/0x19c<br /> | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> Esto se soluciona haciendo que restore_za_context() asegure que el sve_state de la tarea esté asignado, coincidiendo con lo que hacemos al tomar una trampa SME. Cualquier estado SVE/SSVE activo (que se restaura anteriormente desde un contexto de señal separado) debe ser preservado, y por lo tanto no se pone a cero.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> can: usb_8dev: usb_8dev_read_bulk_callback(): corregir fuga de memoria de URB<br /> <br /> Corrige una fuga de memoria similar a la del commit 7352e1d5932a (&amp;#39;can: gs_usb: gs_usb_receive_bulk_callback(): corregir fuga de memoria de URB&amp;#39;).<br /> <br /> En usb_8dev_open() -&amp;gt; usb_8dev_start(), los URB para transferencias USB de entrada se asignan, se añaden al ancla priv-&amp;gt;rx_submitted y se envían. En la función de devolución de llamada completa usb_8dev_read_bulk_callback(), los URB se procesan y se reenvían. En usb_8dev_close() -&amp;gt; unlink_all_urbs(), los URB se liberan llamando a usb_kill_anchored_urbs(&amp;amp;priv-&amp;gt;rx_submitted).<br /> <br /> Sin embargo, esto no tiene en cuenta que el framework USB desancla el URB antes de que se llame a la función completa. Esto significa que una vez que un URB de entrada ha sido completado, ya no está anclado y finalmente no se libera en usb_kill_anchored_urbs().<br /> <br /> Corrige la fuga de memoria anclando el URB en usb_8dev_read_bulk_callback() al ancla priv-&amp;gt;rx_submitted.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fs/writeback: omitir los mapeos AS_NO_DATA_INTEGRITY en wait_sb_inodes()<br /> <br /> Por encima del bucle while() en wait_sb_inodes(), documentamos que debemos esperar por todas las páginas en proceso de escritura para la integridad de los datos. En consecuencia, si un mapeo, como fuse, tradicionalmente no tiene semántica de integridad de datos, no hay necesidad de esperar en absoluto; podemos simplemente omitir estos inodos.<br /> <br /> Esto restaura fuse a su comportamiento anterior donde las sincronizaciones son no-ops. Esto corrige una regresión de usuario donde si un sistema está ejecutando un servidor fuse defectuoso que no responde a las solicitudes de escritura emitidas, esto hace que wait_sb_inodes() espere indefinidamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:<br /> <br /> scsi: core: Despertar al manejador de errores cuando las finalizaciones finales compiten entre sí<br /> <br /> El ordenamiento frágil entre marcar comandos como completados o fallidos, de modo que el manejador de errores solo se despierte cuando el último comando en ejecución se complete o agote el tiempo de espera, tiene condiciones de carrera. Estas condiciones de carrera pueden hacer que la capa SCSI no despierte al manejador de errores, dejando la E/S a través del host SCSI atascada ya que el estado de error no puede avanzar.<br /> <br /> Primero, hay un problema de ordenamiento de memoria dentro de scsi_dec_host_busy(). La escritura que borra SCMD_STATE_INFLIGHT puede reordenarse con lecturas que cuentan en scsi_host_busy(). Si bien la CPU local verá su propia escritura, la reordenación puede permitir que otras CPU en scsi_dec_host_busy() o scsi_eh_inc_host_failed() vean un recuento de ocupación elevado, lo que hace que ninguna CPU vea un host ocupado igual al recuento de host_failed.<br /> <br /> Esta condición de carrera puede evitarse con una barrera de memoria en la ruta de error para forzar que la escritura sea visible antes de contar los comandos de host ocupados.<br /> <br /> Segundo, hay un problema de ordenamiento general con scsi_eh_inc_host_failed(). Al contar los comandos ocupados antes de incrementar host_failed, puede competir con un comando final en scsi_dec_host_busy(), de modo que scsi_dec_host_busy() no ve host_failed incrementado, pero scsi_eh_inc_host_failed() cuenta los comandos ocupados antes de que SCMD_STATE_INFLIGHT sea borrado por scsi_dec_host_busy(), lo que resulta en que ninguno despierte la tarea del manejador de errores.<br /> <br /> Esto requiere que la llamada a scsi_host_busy() se mueva después de que host_failed se incremente para cerrar la condición de carrera.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> iio: dac: ad3552r-hs: corrección de escritura fuera de límites en ad3552r_hs_write_data_source<br /> <br /> Cuando simple_write_to_buffer() tiene éxito, devuelve el número de bytes realmente copiados al búfer. El código usa incorrectamente &amp;#39;count&amp;#39; como índice para la terminación nula en lugar de los bytes realmente copiados. Si count excede el tamaño del búfer, esto lleva a una escritura fuera de límites. Añadir una comprobación para count y usar el valor de retorno como índice.<br /> <br /> El error fue validado usando un módulo de demostración que refleja el código original y fue probado bajo QEMU.<br /> <br /> Patrón del error:<br /> - Un búfer de pila fijo de 64 bytes se llena usando count.<br /> - Si count &amp;gt; 64, el código aún hace buf[count] = &amp;#39;\0&amp;#39;, causando una<br /> - escritura fuera de límites en la pila.<br /> <br /> Pasos para reproducir:<br /> - Abre el nodo del dispositivo.<br /> - Escribe 128 bytes de A en él.<br /> - Esto desborda el búfer de pila de 64 bytes y KASAN reporta el OOB.<br /> <br /> Encontrado mediante análisis estático. Esto es similar al<br /> commit da9374819eb3 (&amp;#39;iio: backend: corrección de escritura fuera de límites&amp;#39;)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> uacce: corrección del manejo de cdev en la ruta de limpieza<br /> <br /> Cuando cdev_device_add falla, libera internamente la memoria de cdev, y si cdev_device_del se ejecuta entonces, causará un error de bloqueo. Para solucionarlo, verificamos el valor de retorno de cdev_device_add() y borramos uacce-&amp;gt;cdev para evitar llamar a cdev_device_del en uacce_remove.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> netrom: soluciona doble liberación en nr_route_frame()<br /> <br /> En nr_route_frame(), old_skb es liberado inmediatamente sin comprobar si el puntero nr_neigh-&amp;gt;ax25 es NULL. Por lo tanto, si nr_neigh-&amp;gt;ax25 es NULL, la función llamadora liberará old_skb de nuevo, causando un error de doble liberación.<br /> <br /> Por lo tanto, para evitar esto, necesitamos modificarlo para comprobar si nr_neigh-&amp;gt;ax25 es NULL antes de liberar old_skb.