Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reinicializar la lista de referencias retrasadas después de eliminarla de la lista En insert_delayed_ref(), si necesitamos actualizar la acción de una referencia existente a BTRFS_DROP_DELAYED_REF, eliminamos la referencia de ref_add_list de su cabecera de referencia usando list_del(), lo que deja el miembro add_list de la referencia sin reinicializar, ya que list_del() establece los miembros siguiente y anterior de la lista en LIST_POISON1 y LIST_POISON2, respectivamente. Si más tarde terminamos llamando a drop_delayed_ref() contra la referencia, lo que puede suceder durante la fusión o al destruir referencias retrasadas debido a un aborto de transacción, podemos provocar un bloqueo ya que en drop_delayed_ref() llamamos a list_empty() contra el add_list de la referencia, que devuelve falso ya que la lista no se reinicializó después de list_del() y, como consecuencia, llamamos a list_del() nuevamente en drop_delayed_ref(). Esto da como resultado un acceso a la lista no válido ya que los miembros next y prev están configurados como punteros envenenados, lo que resulta en un splat si CONFIG_LIST_HARDENED y CONFIG_DEBUG_LIST están configurados o desreferencias de punteros envenenados no válidas en caso contrario. Así que solucione esto eliminando de la lista con list_del_init() en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: vertexcom: mse102x: Se soluciona una posible doble liberación del skb TX El alcance del skb TX es más amplio que solo mse102x_tx_frame_spi(), por lo que en caso de que sea necesario ampliar la sala del skb TX, deberíamos liberar el skb temporal en lugar del skb original. De lo contrario, el puntero TX skb original se liberaría nuevamente en mse102x_tx_work(), lo que provoca fallas: Error interno: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: GD 6.6.23 Nombre del hardware: chargebyte Charge SOM DC-ONE (DT) Cola de trabajo: eventos mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 00000000000000002 x24: 00000000ffffffff x23: 000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 0000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9: ffff00003fd913e8 x8: fffffc00001bc008 x7: 0000000000000000 x6: 0000000000000008 x5: ffff00003fd91340 x4: 00000000000000000 x3 : 0000000000000009 x2 : 00000000ffffffffe x1 : 0000000000000000 x0 : 0000000000000000 Rastreo de llamadas: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Código: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER para GDSC de vcodec Un cambio reciente en el controlador venus da como resultado un reloj atascado en Lenovo ThinkPad X13s, por ejemplo, al transmitir video en Firefox: video_cc_mvs0_clk status stuck at 'off' WARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c ... Rastreo de llamadas: clk_branch_wait+0x144/0x15c clk_branch2_enable+0x30/0x40 clk_core_enable+0xd8/0x29c clk_enable+0x2c/0x4c vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] coreid_power_v4+0x464/0x628 [venus_core] vdec_start_streaming+0xc4/0x510 [venus_dec] vb2_start_streaming+0x6c/0x180 [videobuf2_common] vb2_core_streamon+0x120/0x1dc [videobuf2_common] vb2_streamon+0x1c/0x6c [videobuf2_v4l2] v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] v4l_streamon+0x24/0x30 [videodev] usando el soporte de venus sm8350/sc8280xp fuera del árbol. [1] Actualice también las definiciones GDSC de sm8350/sc8280xp para que el modo de control de hardware se pueda cambiar en tiempo de ejecución como lo requiere ahora el controlador Venus.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock/virtio: inicialización del puntero colgante que se produce en vsk->trans. Durante la comunicación de bucle invertido, se puede crear un puntero colgante en vsk->trans, lo que puede provocar una condición de Use-After-Free. Este problema se resuelve inicializando vsk->trans en NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: eliminar la entrada una vez en lugar de la desreferencia ptr nula en ocfs2_xa_remove() Syzkaller puede provocar la desreferencia ptr nula en ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Truncamiento parcial al eliminar xattr overlay.upper. Fuga de 1 clúster y eliminación de la entrada [ 57.321727] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Seguimiento de llamadas: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] El reproductor utiliza la función faultinject para hacer que ocfs2_xa_remove() -> ocfs2_xa_value_truncate() falle con -ENOMEM. En este caso, el comentario menciona que podemos devolver 0 si ocfs2_xa_cleanup_value_truncate() va a borrar la entrada de todos modos. Pero la siguiente comprobación de 'rc' es incorrecta y el flujo de ejecución ejecuta 'ocfs2_xa_remove_entry(loc);' dos veces: * 1.ª: en ocfs2_xa_cleanup_value_truncate(); * 2.ª: regresa a ocfs2_xa_remove() en lugar de ir a 'out'. Solucione esto omitiendo la segunda eliminación de la misma entrada y haciendo que syzkaller repro funcione correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: serial: io_edgeport: fix use after free in debug printk El "dev_dbg(&urb->dev->dev, ..." que ocurre después de usb_free_urb(urb) es un use after free el puntero "urb". Almacene el puntero "dev" al comienzo de la función para evitar este problema.