Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/timerlat: eliminar interface_lock en stop_kthread() stop_kthread() es la devolución de llamada fuera de línea para "trace/osnoise:online", desde el commit 5bfbcd1ee57b ("tracing/timerlat: agregar interface_lock alrededor de la limpieza de kthread en stop_kthread()"), se introduce el siguiente escenario de bloqueo ABBA: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | Como interface_lock aquí solo sirve para proteger el campo "kthread" de osn_var, utilice xchg() en su lugar para solucionar este problema. Utilice también for_each_online_cpu() en stop_per_cpu_kthreads(), ya que puede volver a activar cpu_read_lock().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vrf: revert "vrf: Remove unexpected RCU-bh critical section" Esto revierte el commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. Se espera que dev_queue_xmit_nit se llame con BH deshabilitado. __dev_queue_xmit tiene lo siguiente: /* Deshabilitar irqs suaves para varios bloqueos a continuación. También * detiene la preempción para RCU. */ rcu_read_lock_bh(); VRF debe seguir esta invariante. el commit a la que se hace referencia eliminó esta protección. Lo que activó una advertencia de lockdep: ================================= ADVERTENCIA: estado de bloqueo inconsistente 6.11.0 #1 Tainted: GW -------------------------------- uso inconsistente de {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W}. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, en: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} el estado se registró en: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] otra información que podría ayudar Depuremos esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(rlock-AF_PACKET); lock(rlock-AF_PACKET); *** BLOQUEO INTERMEDIO *** Seguimiento de llamadas: dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket_rcv+0x863/0x3b30 dev_queue_xmit_nit+0x709/0xa40 vrf_finish_direct+0x26e/0x340 [vrf] vrf_l3_out+0x5f4/0xe80 [vrf] __ip_local_out+0x51e/0x7a0 [...]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Evitar el acceso fuera de los límites en las extensiones de consulta de rendimiento. Compruebe que la cantidad de espacio de usuario de perfmons que pasa en las extensiones de copia y restablecimiento no sea mayor que el almacenamiento interno del kernel donde se copiarán los identificadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: se agregaron campos del contador de recuento con RTL8125. RTL8125 agregó campos al contador de recuento, lo que puede provocar que el chip desactive estos nuevos campos en la memoria no asignada. Por lo tanto, asegúrese de que el área de memoria asignada sea lo suficientemente grande como para contener todos los valores del contador de recuento, incluso si solo usamos partes de ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: Limitar el número de operaciones de COPIA asíncronas concurrentes No parece que nada limite el número de operaciones de COPIA asíncronas concurrentes que los clientes pueden iniciar. Además, según tengo entendido, cada COPIA asíncrona puede copiar una cantidad ilimitada de fragmentos de 4 MB, por lo que puede ejecutarse durante mucho tiempo. Por lo tanto, en mi opinión, la COPIA asíncrona puede convertirse en un vector de denegación de servicio (DoS). Agregue un mecanismo de restricción que limite el número de operaciones de COPIA en segundo plano concurrentes. Comience de manera simple e intente ser justo: este parche implementa un límite por espacio de nombres. Una solicitud de COPIA asíncrona que se produce mientras se excede este límite obtiene NFS4ERR_DELAY. El cliente solicitante puede elegir enviar la solicitud nuevamente después de un retraso o volver a una copia de estilo de lectura/escritura tradicional. Si es necesario hacer que el mecanismo sea más sofisticado, podemos tratarlo en parches futuros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uprobes: se corrige la fuga de información del kernel a través de "[uprobes]" vma xol_add_vma() asigna la página no inicializada asignada por __create_xol_area() al espacio de usuario. En algunas arquitecturas (x86), esta memoria se puede leer incluso sin VM_READ, VM_EXEC da como resultado el mismo pgprot_t que VM_EXEC|VM_READ, aunque esto realmente no importa, el depurador puede leer esta memoria de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: Fix zero-division error when disabling tc cbs el commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") permite que "port_transmit_rate_kbps" se establezca en un valor de 0, que luego se pasa a la función "div_s64" cuando tc-cbs está deshabilitado. Esto conduce a un error de división por cero. Cuando tc-cbs está deshabilitado, no es necesario configurar los valores idleslope, sendslope y credit. Por lo tanto, agregar una declaración de retorno después de establecer el modo txQ en DCB cuando tc-cbs está deshabilitado evitaría un error de división por cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gso: arregla la segmentación de fraglist gso udp después de extraer de frag_list Detecta skbs de fraglist gso con geometría corrupta (ver abajo) y pásalos a skb_segment en lugar de a skb_segment_list, ya que el primero puede segmentarlos correctamente. Skbs SKB_GSO_FRAGLIST válidos: consisten en dos o más segmentos: el head_skb contiene los encabezados de protocolo más el primero gso_size: uno o más skbs de frag_list contienen exactamente un segmento: todos menos el último deben ser gso_size Los ganchos de ruta de datos opcionales como NAT y BPF (bpf_skb_pull_data) pueden modificar estos skbs, rompiendo estos invariantes. En casos extremos, extraen todos los datos en skb lineal. Para UDP, esto provoca un desreferenciado de ptr NULL en __udpv4_gso_segment_list_csum en udp_hdr(seg->next)->dest. Detecta geometría no válida debido a la extracción, verificando el tamaño de head_skb. No la elimines, ya que esto puede convertir un destino en un agujero negro. Convierte para poder pasar a skb_segment normal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: se corrige el error de use after free en venus_remove debido a la condición de ejecución en venus_probe, core->work está vinculado con venus_sys_error_handler, que se usa para manejar el error. El código usa core->sys_err_done para que funcione la sincronización. El core->work se inicia en venus_event_notify. Si llamamos a venus_remove, puede haber un trabajo sin pescar. La secuencia posible es la siguiente: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Arréglelo cancelando el trabajo en venus_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: aoe: soluciona el posible problema de use-after-free en más lugares Para solucionar CVE-2023-6270, f98364e92662 ("aoe: soluciona el posible problema de use-after-free en aoecmd_cfg_pkts") hace que tx() llame a dev_put() en lugar de hacerlo en aoecmd_cfg_pkts(). Esto evita que tx() se ejecute en use-after-free. Luego, Nicolai Stange encontró que más lugares en aoe tienen un posible problema de use-after-free con tx(). Por ejemplo, revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Esas funciones también usan aoenet_xmit() para enviar paquetes a la cola de tx. Por lo tanto, también deberían usar dev_hold() para aumentar el refcnt de skb->dev. Por otra parte, mover dev_put() a tx() hace que el refcnt de skb->dev se reduzca a un valor negativo, porque los dev_hold() correspondientes no se llaman en revalidate(), aoecmd_ata_rw(), resend(), probe() y aoecmd_cfg_rsp(). Este parche solucionó este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: eliminar ppath de ext4_ext_replay_update_ex() para evitar una doble liberación Al llamar a ext4_force_split_extent_at() en ext4_ext_replay_update_ex(), se actualiza 'ppath' pero es 'path' el que se libera, lo que potencialmente desencadena una doble liberación en el siguiente proceso: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path Primero liberado *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! Por lo tanto, elimine el ppath innecesario y use path directamente para evitar este problema. Y use ext4_find_extent() directamente para actualizar path, evitando la asignación y liberación de memoria innecesaria. Además, propague el error devuelto por ext4_find_extent() en lugar de usar códigos de error extraños.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: stm32f7: No preparar/despreparar el reloj durante la suspensión/reanudación en tiempo de ejecución En caso de que haya algún tipo de controlador de reloj conectado a este controlador de bus I2C, por ejemplo Versaclock o incluso un códec I2C AIC32x4, entonces una transferencia I2C activada desde la devolución de llamada clk_ops .prepare del controlador de reloj puede activar un bloqueo en el mutex prepare_lock de drivers/clk/clk.c. Esto se debe a que el controlador de reloj primero toma el mutex prepare_lock y luego realiza la operación de preparación, incluido su acceso I2C. El acceso I2C reanuda este controlador de bus I2C a través de la devolución de llamada .runtime_resume, que llama a clk_prepare_enable(), que intenta tomar el mutex prepare_lock nuevamente y se bloquea. Dado que el reloj ya está preparado desde probe() y no preparado en remove(), use llamadas clk_enable()/clk_disable() simples para habilitar y deshabilitar el reloj en la suspensión y reanudación del tiempo de ejecución, para evitar alcanzar el mutex prepare_lock.