Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medios: usbtv: Eliminar bloqueos inútiles en usbtv_video_free() Eliminar llamadas de bloqueos en usbtv_video_free() porque son inútiles y pueden provocar un punto muerto como se informa aquí: https://syzkaller.appspot .com/x/bisect.txt?x=166dc872180000 También elimine la llamada usbtv_stop() ya que se llamará al cancelar el registro del dispositivo. Antes de 'c838530d230b', este problema solo se notaba si se desconectaba mientras se transmitía y ahora se nota incluso cuando se desconecta mientras no se transmite. [hverkuil: corrige un error ortográfico menor en el mensaje de registro]

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925e: fix use-after-free in free_irq() Desde el commit a304e1b82808 ("[PATCH] Depurar irqs compartidas"), existe una prueba para asegurarse de que El controlador de irq compartido debería poder manejar el evento inesperado después de la cancelación del registro. Para este caso, apliquemos el indicador MT76_REMOVED para indicar que el dispositivo fue eliminado y que ya no se puede acceder al recurso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: libbpf: use la macro OPTS_SET() en bpf_xdp_query() Cuando los campos feature_flags y xdp_zc_max_segs se agregaron a libbpf bpf_xdp_query_opts, el código que los escribió no usó la macro OPTS_SET(). Esto hace que libbpf escriba en esos campos incondicionalmente, lo que significa que los programas compilados con una versión anterior de libbpf (con un tamaño más pequeño de la estructura bpf_xdp_query_opts) tendrán su pila dañada por la escritura de libbpf fuera de los límites. El parche que agrega el campo feature_flags tiene un rescate anticipado si el campo feature_flags no es parte de la estructura opts (a través de la macro OPTS_HAS), pero el parche que agrega xdp_zc_max_segs no lo hace. Para mantener la coherencia, esta solución simplemente cambia las asignaciones a ambos campos para usar la macro OPTS_SET().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cpufreq: brcmstb-avs-cpufreq: agregar verificación para el valor de retorno de cpufreq_cpu_get cpufreq_cpu_get puede devolver NULL. Para evitar la desreferencia NULL, verifíquelo y devuelva 0 en caso de error. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtl8xxxu: agregue cancel_work_sync() para c2hcmd_work Es posible que la cola de trabajo aún esté ejecutándose cuando se detiene el controlador. Para evitar un use-after-free, llame a cancel_work_sync() en rtl8xxxu_stop().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wilc1000: corrige el uso de RCU en la ruta de conexión Con lockdep habilitado, las llamadas a la función de conexión desde la capa cfg802.11 generan la siguiente advertencia: ======== ====================== ADVERTENCIA: uso sospechoso de RCU 6.7.0-rc1-wt+ #333 No contaminado ------------- ---------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 ¡uso sospechoso de rcu_dereference_check()! [...] pila backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant No está contaminado 6.7.0-rc1-wt+ #333 Nombre de hardware: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_para m +0x7dc/0x7f4 wilc_parse_join_bss_param desde connect+0x2c4/0x648 conectar desde cfg80211_connect+0x30c/0xb74 cfg80211_connect desde nl80211_connect+0x860/0xa94 nl80211_connect desde genl_rcv_msg+0x3fc /0x59c genl_rcv_msg de netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb de genl_rcv+0x2c/0x3c genl_rcv de netlink_unicast+ 0x3b0/0x550 netlink_unicast de netlink_sendmsg+0x368/0x688 netlink_sendmsg de ____sys_sendmsg+0x190/0x430 ____sys_sendmsg de ___sys_sendmsg+0x110/0x158 ___sys_sendmsg de sys_sendmsg +0xe8/0x150 sys_sendmsg de ret_fast_syscall+0x0/0x1c Esta advertencia se emite porque en la ruta de conexión, al intentar Para analizar los parámetros BSS de destino, eliminamos la referencia a un puntero de RCU sin estar en la sección crítica de RCU. Corrija el uso de desreferenciación de RCU moviéndolo a una sección crítica de lectura de RCU. Para evitar incluir todo el wilc_parse_join_bss_param en la sección crítica, simplemente use la sección crítica para copiar datos de ies

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/dasd: corrige la disminución del doble recuento del módulo Una vez que la disciplina está asociada con el dispositivo, eliminar el dispositivo se encarga de disminuir el recuento del módulo. Hacerlo manualmente en esta ruta de error hace que el recuento disminuya artificialmente en cada error, mientras que debería permanecer igual.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cola de trabajo: no llame a cpumask_test_cpu() con -1 CPU en wq_update_node_max_active() Para wq_update_node_max_active(), @off_cpu de -1 indica que no hay ninguna CPU fallando. La función llamaba incorrectamente a cpumask_test_cpu() con -1 CPU, lo que provocaba errores como los siguientes en algunos arcos: No se puede manejar la solicitud de paginación del kernel en la dirección virtual ffff0002100296e0 .. pc: wq_update_node_max_active+0x50/0x1fc lr: wq_update_node_max_active+0x1f0/0x1fc .. Seguimiento de llamadas: wq_update_node_max_active+0x50/0x1fc apply_wqattrs_commit+0xf0/0x114 apply_workqueue_attrs_locked+0x58/0xa0 alloc_workqueue+0x5ac/0x774 workqueue_init_early+0x460/0x540 start_kernel+0x258/0x68. 4 __primary_switched+0xb8/0xc0 Código: 9100a273 35000d01 53067f00 d0016dc1 (f8607a60) -- -[ end trace 0000000000000000 ]--- Pánico del kernel - no se sincroniza: ¡Se intentó finalizar la tarea inactiva! ---[ fin del pánico del kernel: no se sincroniza: ¡se intentó finalizar la tarea inactiva! ]--- Arreglalo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: SOF: ipc4-pcm: workaround para firmware bloqueado en suspensión del sistema Cuando el sistema se suspende mientras el audio está activo, se invoca sof_ipc4_pcm_hw_free() para restablecer las canalizaciones desde durante la suspensión el DSP está apagado, las transmisiones se reiniciarán después de reanudarse. Si el firmware falla mientras se ejecuta el audio (o cuando reiniciamos la transmisión antes de suspenderla), entonces sof_ipc4_set_multi_pipeline_state() fallará con un error de IPC y se interrumpirá el cambio de estado. Esto provocará una desalineación entre el estado del kernel y del firmware en el siguiente arranque del DSP, lo que provocará errores devueltos por el firmware para los mensajes IPC, lo que eventualmente provocará un error en la reanudación del audio. Al cerrar la transmisión, los errores se ignoran, por lo que el estado del kernel se corregirá en el siguiente inicio del DSP, es decir, en el segundo inicio después del pánico del DSP. Si se llama a sof_ipc4_trigger_pipelines() desde sof_ipc4_pcm_hw_free() entonces el parámetro de estado es SOF_IPC4_PIPE_RESET y solo en este caso. Trate un reinicio forzado de canalización de manera similar a como tratamos un pcm_free ignorando el error en el envío del estado para permitir que el estado del kernel sea consistente con el estado que tendrá el firmware después del siguiente arranque.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tmpfs: corrige la ejecución al manejar dquot rbtree Un reproductor syzkaller encontró una ejecución al intentar eliminar información de dquot del árbol rb. La recuperación del nodo raíz de rb_tree también debe estar protegida por dqopt->dqio_sem; de lo contrario, si se da el momento adecuado, shmem_release_dquot() activará una advertencia porque no pudo encontrar un nodo en el árbol, cuando la verdadera razón era el nodo raíz. cambiando antes de que comience la búsqueda: Hilo 1 Hilo 2 - shmem_release_dquot() - shmem_{acquire,release}_dquot() - buscar ROOT - Obtener ROOT - adquirir dqio_sem - esperar dqio_sem - hacer algo, activar un reequilibrio de árbol - liberar dqio_sem - adquirir dqio_sem - comienza a buscar el nodo, pero desde la ubicación incorrecta, pierde el nodo y genera una advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: almacenamiento-usb: evita el error de división por 0 en isd200_ata_command El subcontrolador isd200 en almacenamiento-usb utiliza los valores HEADS y SECTORES en la información de ID de ATA para calcular el cilindro y valores principales al crear un CDB para comandos LEER o ESCRIBIR. El cálculo implica operaciones de división y módulo, lo que provocará un bloqueo si cualquiera de estos valores es 0. Si bien esto nunca sucede con un dispositivo genuino, podría suceder con una emulación defectuosa o subversiva, según lo informado por syzbot fuzzer. Protéjase contra esta posibilidad negándose a vincularse al dispositivo si el valor ATA_ID_HEADS o ATA_ID_SECTORS en la información de ID del dispositivo es 0. Esto requiere que isd200_Initialization() devuelva un código de error negativo cuando falla la inicialización; actualmente siempre devuelve 0 (incluso cuando hay un error).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thunderbolt: corrige la desreferencia del puntero NULL en tb_port_update_credits() Olliver informó que su sistema falla al conectar el dispositivo Thunderbolt 1: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000020 #PF: supervisor leído acceso en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Vaya: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:tb_port_do_update_credits+0x1b/0x130 [thunderbolt] Seguimiento de llamadas: ? __morir+0x23/0x70 ? page_fault_oops+0x171/0x4e0? exc_page_fault+0x7f/0x180? asm_exc_page_fault+0x26/0x30? tb_port_do_update_credits+0x1b/0x130 ? tb_switch_update_link_attributes+0x83/0xd0 tb_switch_add+0x7a2/0xfe0 tb_scan_port+0x236/0x6f0 tb_handle_hotplug+0x6db/0x900 Process_one_work+0x171/0x340 Workers_thread+0x27b/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Esto se debe al hecho de que algunos dispositivos Thunderbolt 1 solo tienen un adaptador de línea. Solucione este problema comprobando el carril 1 antes de leer sus créditos.