Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: corrige el acceso fuera de los límites al conjunto de bits sucio al cambiar el tamaño dm-cache verifica los bits sucios de los bloques de caché que se deben descartar al reducir el dispositivo rápido, pero un error de índice en la iteración del conjunto de bits provoca un acceso fuera de los límites. Reproducir los pasos: 1. crear un dispositivo de caché de 1024 bloques de caché (128 bytes de bitset sucio) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. reducir el dispositivo rápido a 512 bloques de caché, lo que activa el acceso fuera de los límites al bitset sucio. bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN informa: ERROR: KASAN: vmalloc-out-of-bounds en cache_preresume+0x269/0x7b0 Lectura de tamaño 8 en la dirección ffffc900000f3080 por la tarea dmsetup/131 (...snip...) La dirección con errores pertenece al mapeo virtual en [ffffc900000f3000, ffffc900000f5000) creado por: cache_ctr+0x176a/0x35f0 (...snip...) Estado de la memoria alrededor de la dirección con errores: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm cache: fix flushing uninitialized delayed_work on cache_ctr error Se puede producir un WARN_ON inesperado de flush_work() cuando falla la creación de caché, causado por la destrucción del activador delayed_work no inicializado en la ruta de error de cache_create(). Por ejemplo, la advertencia aparece en el error de suma de comprobación del superbloque. Reproducir los pasos: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" Registros del kernel: (fragmento) ADVERTENCIA: CPU: 0 PID: 84 en kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Se soluciona extrayendo cancel_delayed_work_sync() de la ruta de error del constructor. Este parche no afecta la corrección de use-after-free para dm_resume y dm_destroy simultáneos (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) ya que cache_dtr no se modifica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: agregar comprobación de tamaño faltante en amdgpu_debugfs_gprwave_read() Evitar un posible desbordamiento de búfer si el tamaño es mayor a 4K. (seleccionado de el commit f5d873f5825b40d886d03bd2aede91d4cf002434)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige slab-use-after-free en smb3_preauth_hash_rsp. ksmbd_user_session_put debe llamarse bajo smb3_preauth_hash_rsp(). Esto evitará liberar la sesión antes de llamar a smb3_preauth_hash_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: Se corrige el error xa_store faltante. La comprobación xa_store() puede fallar, devuelve xa_err(-EINVAL) si la entrada no se puede almacenar en un XArray, o xa_err(-ENOMEM) si falla la asignación de memoria, por lo que se debe verificar el error de xa_store() para solucionarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige slab-use-after-free en ksmbd_smb2_session_create. Existe una condición de ejecución entre ksmbd_smb2_session_create y ksmbd_expire_session. Este parche agrega el bloqueo sessions_table_lock faltante al agregar o eliminar una sesión de la tabla de sesiones global.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: v4l2-tpg: evitar el riesgo de una división por cero Como lo informó Coverity, la lógica en tpg_precalculate_line() reescala ciegamente el búfer incluso cuando scaled_witdh es igual a cero. Si esto sucede alguna vez, provocará una división por cero. En su lugar, agregue un WARN_ON_ONCE() para activar dichos casos y regresar sin realizar ningún cálculo previo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/core: evitar desbordamientos en damon_feed_loop_next_input() damon_feed_loop_next_input() es ineficiente y frágil a desbordamientos. Específicamente, el cálculo de 'score_goal_diff_bp' puede desbordarse cuando 'score' es alto. El cálculo es realmente innecesario en absoluto porque 'goal' es una constante de valor 10,000. El cálculo de 'compensación' es nuevamente frágil a desbordamientos. El cálculo final del valor de retorno para el caso de bajo rendimiento es nuevamente frágil a desbordamientos cuando el puntaje actual no alcanza el objetivo. Agregue dos casos extremos de manejo al comienzo de la función para hacer que el cuerpo sea más fácil de leer y reescriba el cuerpo de la función para evitar desbordamientos y el cálculo innecesario del valor bp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: evitar el acceso a vport en idpf_get_link_ksettings Cuando se elimina el plano de control del dispositivo o se reinicia la plataforma que ejecuta el plano de control del dispositivo, se detecta un reinicio en el controlador. Al reiniciar el controlador, libera los recursos y espera a que se complete el reinicio. Si el reinicio falla, toma la ruta de error y libera el bloqueo de vport. En este momento, si las herramientas de monitoreo intentan acceder a la configuración del enlace, invocan seguimientos para acceder al puntero de vport liberado. Para evitarlo, mueva link_speed_mbps a la estructura netdev_priv que elimina la dependencia del puntero de vport y el bloqueo de vport en idpf_get_link_ksettings. También use netif_carrier_ok() para verificar el estado del enlace y ajuste el offsetof para usar link_up en lugar de link_speed_mbps.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/sve: descartar estado de CPU obsoleto al manejar trampas SVE La lógica para manejar trampas SVE manipula incorrectamente el estado FPSIMD/SVE guardado, y una ejecución con preempción puede resultar en una tarea que tenga TIF_SVE establecido y TIF_FOREIGN_FPSTATE borrado incluso aunque el estado de CPU en vivo esté obsoleto (por ejemplo, con trampas SVE habilitadas). Se ha observado que esto da como resultado advertencias de do_sve_acc() donde no se esperan trampas SVE mientras TIF_SVE está establecido: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* El acceso a SVE no debería haber generado una trampa */ Se han informado advertencias de este formato de forma intermitente, por ejemplo, https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ La ejecución puede ocurrir cuando el controlador de trampa SVE se interrumpe antes y después de manipular el estado FPSIMD/SVE guardado, comenzando y terminando en la misma CPU, por ejemplo, | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trampa en CPU 0 con TIF_SVE limpio, trampas SVE habilitadas | // task->fpsimd_cpu es 0. | // per_cpu_ptr(&fpsimd_last_state, 0) es la tarea. | | ... | | // Preempleado; migrado de la CPU 0 a la CPU 1. | // TIF_FOREIGN_FPSTATE está establecido. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* El acceso a SVE no debería haber quedado atrapado */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempleado; migrado de CPU 1 a CPU 0. | // task->fpsimd_cpu sigue siendo 0 | // Si per_cpu_ptr(&fpsimd_last_state, 0) sigue siendo tarea entonces: | // - Se reutiliza el estado de HW obsoleto (con trampas SVE habilitadas) | // - Se borra TIF_FOREIGN_FPSTATE | // - Un retorno al espacio de usuario omite la restauración del estado de HW | } Corrija el caso donde el estado no está activo y TIF_FOREIGN_FPSTATE se establece llamando a fpsimd_flush_task_state() para separarse del estado de CPU guardado. Esto garantiza que un cambio de contexto posterior no reutilizará el estado de CPU obsoleto y, en su lugar, establecerá TIF_FOREIGN_FPSTATE, lo que obligará a que el nuevo estado se vuelva a cargar desde la memoria antes de un retorno al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: señal: restaurar la lógica override_rlimit Antes de el commit d64696905554 ("Reimplementar RLIMIT_SIGPENDING sobre ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit no se aplicaba para una clase de señales. Sin embargo, ahora se aplica de forma incondicional, incluso si se establece override_rlimit. Este cambio de comportamiento provocó problemas de producción. Por ejemplo, si se alcanza el límite y un proceso recibe una señal SIGSEGV, sigqueue_alloc no puede asignar los recursos necesarios para la entrega de la señal, lo que impide que la señal se entregue con siginfo. Esto impide que el proceso identifique correctamente la dirección de falla y maneje el error. Desde la perspectiva del espacio de usuario, las aplicaciones no saben que se ha alcanzado el límite y que la siginfo está efectivamente "corrupta". Esto puede provocar un comportamiento impredecible y fallas, como observamos con las aplicaciones Java. Solucione este problema pasando override_rlimit a inc_rlimit_get_ucounts() y omita la comparación con max allí si se configura override_rlimit. Esto restaura efectivamente el comportamiento anterior.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: filemap: Se ha corregido la comprobación de los límites en filemap_read() Si el llamador proporciona un valor iocb->ki_pos que está cerca del límite superior del sistema de archivos y un iterador con un recuento que hace que desbordemos ese límite, filemap_read() entra en un bucle infinito. Este comportamiento se descubrió al probar xfstests generic/525 con la optimización "localio" para montajes NFS de bucle invertido.