Vulnerabilidades

Se ha encontrado una vulnerabilidad clasificada como problemática en ruifang-tech Rebuild 3.8.6. Afecta a una parte desconocida del archivo /project/050-9000000000000001/tasks del componente Project Tasks Section. La manipulación de la descripción del argumento provoca cross site scripting. Es posible iniciar el ataque de forma remota. El exploit se ha divulgado al público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta divulgación, pero no respondió de ninguna manera.

Se ha encontrado una vulnerabilidad en running-elephant Datart 1.0.0-rc3. Se ha calificado como crítica. Este problema afecta a la función extractModel del archivo /import del componente File Upload. La manipulación del archivo de argumentos provoca la deserialización. El ataque puede ejecutarse de forma remota. El exploit se ha divulgado al público y puede utilizarse. Se contactó al proveedor con anticipación sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/igen6: Evitar fallo de segmentación al descargar el módulo El fallo de segmentación ocurre porque: Durante modprobe: 1. En igen6_probe(), igen6_pvt se asignará con kzalloc() 2. En igen6_register_mci(), mci->pvt_info apuntará a &igen6_pvt->imc[mc] Durante rmmod: 1. En mci_release() en edac_mc.c, kfree(mci->pvt_info) 2. En igen6_remove(), kfree(igen6_pvt); Solucione este problema configurando mci->pvt_info en NULL para evitar el kfree doble.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/cpum_sf: Reparar y proteger la asignación de memoria de los SDB con mutex La reserva del hardware de la PMU se realiza en la primera creación del evento y está protegida por un par de mutex_lock() y mutex_unlock(). Después de la reserva del hardware de la PMU, la memoria requerida para las PMU en las que se instalará el evento se asigna mediante allocate_buffers() y alloc_sampling_buffer(). Esto se hace fuera de la protección mutex. Sin la protección mutex, dos o más invocaciones simultáneas de perf_event_init() pueden ejecutarse en paralelo. Esto puede provocar la asignación de bloques de datos de muestra (SDB) varias veces para la misma PMU. Evite esto y proteja la asignación de memoria de los SDB mediante mutex.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: gestionar errores otx2_mbox_get_rsp en otx2_dmac_flt.c Agregar comprobaciones de puntero de error después de llamar a otx2_mbox_get_rsp().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: atomisp: Se ha añadido una comprobación para detectar un error en la asignación de memoria de rgby_data En ia_css_3a_statistics_allocate(), no se realiza ninguna comprobación del resultado de la asignación de la memoria rgby_data. Si rgby_data no se asigna correctamente, puede activar la aserción assert(host_stats->rgby_data) en ia_css_s3a_hmem_decode(). Se ha añadido una comprobación para solucionar este posible problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: Se han observado bloqueos suaves en fib6_select_path bajo una alta rotación del siguiente salto. Se han observado bloqueos suaves en un clúster del routeres de borde basados en Linux ubicados en un entorno altamente dinámico. Al usar el servicio `bird`, estos routeres actualizan continuamente las rutas anunciadas por BGP debido a que cambian con frecuencia los destinos del siguiente salto, al mismo tiempo que administran un tráfico IPv6 significativo. Los bloqueos ocurren durante el recorrido de la lista enlazada circular de múltiples rutas en la función `fib6_select_path`, particularmente mientras se itera a través de los hermanos en la lista. El problema generalmente surge cuando los nodos de la lista enlazada se eliminan inesperadamente de manera concurrente en un núcleo diferente, lo que se indica mediante sus elementos 'next' y 'previous' que apuntan al nodo mismo y su recuento de referencia cae a cero. Esto da como resultado un bucle infinito, lo que lleva a un bloqueo suave que desencadena un pánico del sistema a través del temporizador de vigilancia. Aplique primitivas RCU en las secciones de código problemáticas para resolver el problema. Cuando sea necesario, actualice las referencias a fib6_siblings para anotar o usar las API de RCU. Incluya un script de prueba que reproduzca el problema. El script actualiza periódicamente la tabla de enrutamiento mientras genera una gran carga de tráfico IPv6 saliente a través de varios clientes iperf3. Induce constantemente bloqueos suaves infinitos en un par de minutos. Registro del núcleo: 0 [ffffbd13003e8d30] machine_kexec en ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec en ffffffff8d0120e3 2 [ffffbd13003e8e58] pánico en ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn en ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues en ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt en ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt en ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt en ffffffff8df1b83d -- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt en ffffffff8e000ecb [excepción RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 000000000000000 R9: ffff975850b40200 R10: 000000000000000 R11: 000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 00000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ruta_pol_ip6 en ffffffff8ddb030c 10 [ffffbd13003d3888] entrada_ruta_pol_ip6 en ffffffff8ddb068c 11 [ffffbd13003d3898] búsqueda_regla_fib6 en ffffffff8ddf02b5 12 [ffffbd13003d3928] entrada_ruta_ip6 en ffffffff8ddb0f47 13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 en ffffffff8dd950d0 14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 en ffffffff8dd96274 15 [ffffbd13003d3a98] ip6_sublist_rcv en ffffffff8dd96474 16 [ffffbd13003d3af8] ipv6_list_rcv en ffffffff8dd96615 17 [ffffbd13003d3b60] __netif_receive_skb_list_core en ffffffff8dc16fec 18 [ffffbd13003d3be0] netif_receive_skb_list_internal en ffffffff8dc176b3 19 [ffffbd13003d3c50] napi_gro_receive en ffffffff8dc565b9 20 [ffffbd13003d3c80] ice_receive_skb en ffffffffc087e4f5 [hielo] 21 [ffffbd13003d3c90] ice_clean_rx_irq en ffffffffc0881b80 [hielo] 22 [ffffbd13003d3d20] ice_napi_poll en ffffffffc088232f [hielo] 23 [ffffbd13003d3d80] __napi_poll en ffffffff8dc18000 24 [ffffbd13003d3db8] net_rx_action en ffffffff8dc18581 25 [ffffbd13003d3e40] __do_softirq en ffffffff8df352e9 26 [ffffbd13003d3eb0] run_ksoftirqd en ffffffff8ceffe47 27 [ffffbd13003d3ec0] smpboot_thread_fn en ffffffff8cf36a30 28 [ffffbd13003d3ee8] kthread en ffffffff8cf2b39f 29 [ffffbd13003d3f28] ret_from_fork en ffffffff8ce5fa64 30 [ffffbd13003d3f50] ret_from_fork_asm en ffffffff8ce03cbb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/xen: se corrige la liberación de IRQ. Los registros del kernel indican que se liberó una IRQ dos veces. Se pasa la identificación del dispositivo correcta durante la liberación de IRQ. [Dominique: se elimina la variable confusa que se restablece a 0]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/pci: Arreglar posible doble eliminación de ranura hotplug En el commit 6ee600bfbe0f ("s390/pci: eliminar ranura hotplug al liberar el dispositivo"), zpci_exit_slot() se movió de zpci_device_reserved() a zpci_release_device() con la intención de mantener la ranura hotplug hasta que el dispositivo sea realmente eliminado. Ahora, zpci_release_device() solo se llama una vez que se eliminan todas las referencias. Dado que el subsistema zPCI solo elimina su referencia una vez que el dispositivo está en el estado reservado, se deduce que zpci_release_device() solo debe tratar con dispositivos en el estado reservado. A pesar de eso, contiene código para desmantelar tanto el estado configurado como el de espera. Para el caso de espera, esto ya incluye la eliminación de la ranura hotplug, por lo que causaría una doble eliminación si un dispositivo alguna vez se eliminara en estado configurado o de espera. En lugar de provocar una posible doble eliminación en un caso que nunca debería ocurrir, use WARN_ON() explícitamente si se libera un dispositivo en estado no reservado y elimine los casos de código inactivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Marcar argumentos raw_tp con PTR_MAYBE_NULL Los argumentos para un tracepoint sin procesar se etiquetan como confiables, lo que conlleva la semántica de que el puntero no será NULL. Sin embargo, en ciertos casos, un argumento de tracepoint sin procesar puede terminar siendo NULL. Hay más contexto disponible sobre este problema en [0]. Por lo tanto, existe una discrepancia entre la realidad, que los argumentos raw_tp pueden ser NULL, y el conocimiento del verificador, de que nunca son NULL, lo que hace que se eliminen las comprobaciones NULL explícitas y los accesos a dichos punteros potencialmente bloqueen el kernel. Para solucionar esto, marque los argumentos raw_tp como PTR_MAYBE_NULL y luego aplique un caso especial a la desreferencia y la aritmética de punteros para permitirlo, y permita pasarlos a ayudantes/kfuncs; estas excepciones se realizan solo para programas raw_tp. Asegúrese de no hacer esto cuando ref_obj_id > 0, ya que en ese caso se trata de un objeto adquirido y no necesita dicho ajuste. La razón por la que hacemos la lógica mask_raw_tp_trusted_reg es porque otros volverán a verificar en algunos lugares si el registro es un trusted_reg y luego considerarán nuestro registro como no confiable al detectar la presencia del indicador PTR_MAYBE_NULL. Para permitir una desreferencia segura, habilitamos el marcado PROBE_MEM cuando vemos cargas en punteros confiables con PTR_MAYBE_NULL. Si bien los argumentos raw_tp confiables también se pueden pasar a los ayudantes o kfuncs donde tal suposición rota puede causar problemas, un futuro conjunto de parches abordará su caso por separado, ya que PTR_TO_BTF_ID (sin PTR_TRUSTED) ya se puede pasar a los ayudantes y causa problemas similares. Por lo tanto, se dejan solos por ahora. Es posible que estas verificaciones también permitan pasar argumentos que no sean raw_tp que sean PTR_TO_BTF_ID confiables con marcado nulo. En tal caso, permitir la desreferencia cuando el puntero es NULL expande el comportamiento permitido, por lo que no se producirá una regresión de los programas existentes, y el caso de pasarlos a los ayudantes es el mismo que el anterior y se tratará más adelante. También actualice el caso de falla en la autoprueba tp_btf_nullable para capturar el nuevo comportamiento, ya que el verificador ya no provocará un error cuando desreferencia directamente un argumento de punto de seguimiento sin formato marcado como __nullable. [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: wl128x: Se corrige la violación de atomicidad en fmc_send_cmd() La violación de atomicidad ocurre cuando la función fmc_send_cmd() se ejecuta simultáneamente con la modificación del valor fmdev->resp_skb. Considere un escenario donde, después de pasar la verificación de validez dentro de la función, a una variable fmdev->resp_skb no nula se le asigna un valor nulo. Esto da como resultado una variable fmdev->resp_skb no válida que pasa la verificación de validez. Como se ve en la parte posterior de la función, skb = fmdev->resp_skb; cuando la fmdev->resp_skb no válida pasa la verificación, puede ocurrir un error de desreferencia de puntero nulo en la línea 478, evt_hdr = (void *)skb->data; Para solucionar este problema, se recomienda incluir la comprobación de validez de fmdev->resp_skb dentro de la sección bloqueada de la función. Esta modificación garantiza que el valor de fmdev->resp_skb no cambie durante el proceso de validación, manteniendo así su validez. Este posible error se detecta mediante una herramienta de análisis estático experimental desarrollada por nuestro equipo. Esta herramienta analiza las API de bloqueo para extraer pares de funciones que se pueden ejecutar simultáneamente y, a continuación, analiza las instrucciones en las funciones emparejadas para identificar posibles errores de concurrencia, incluidas las ejecucións de datos y las violaciones de atomicidad.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/pseries: Se corrige que dtl_access_lock sea un rw_semaphore. El dtl_access_lock debe ser un rw_sempahore, un bloqueo inactivo, porque el código llama a kmalloc() mientras lo mantiene, lo que puede inactivar: # echo 1 > /proc/powerpc/vcpudispatch_stats ERROR: función inactiva llamada desde un contexto no válido en include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 bloqueos mantenidos por sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, en: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, en: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, en: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh No contaminado 6.10.0-rc4 #152 Nombre del hardware: IBM pSeries (emulado por qemu) POWER9 (sin procesar) 0x4e1202 0xf000005 de:SLOF,HEAD hv:linux,kvm Rastreo de llamadas de pSeries: dump_stack_lvl+0x130/0x148 (no confiable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 excepción_de_llamada_al_sistema+0x1c4/0x5a0 llamada_al_sistema_común+0xf4/0x258