Vulnerabilidades

Una vulnerabilidad ha sido encontrada en Tosei Online Store Management System 4.02/4.03/4.04 y clasificada como crítica. Esto afecta a una parte desconocida del archivo /cgi-bin/tosei_kikai.php. La manipulación del argumento kikaibangou conduce a la inyección de comandos. Es posible iniciar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

Se encontró una vulnerabilidad en Tosei Online Store Management System 4.02/4.03/4.04. Ha sido calificada como crítica. Una función desconocida del archivo /cgi-bin/p1_ftpserver.php es afectada por esta vulnerabilidad. La manipulación del argumento adr_txt conduce a la inyección de comandos. El ataque puede lanzarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

El complemento ARMember – Membership Plugin, Content Restriction, Member Levels, User Profile & User signup para WordPress es vulnerable a Cross-Site Scripting Almacenado a través de cargas de archivos SVG en todas las versiones hasta la 4.0.37 incluida debido a una desinfección de entrada insuficiente y salida que se escapa. Esto hace posible que atacantes autenticados, con acceso de nivel de suscriptor y superior, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda al archivo SVG.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: arreglar el trabajo de desmontaje de TTLM El trabajador calcula el puntero sdata incorrecto, por lo que si alguna vez se ejecuta, fallará. Arregla eso.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc: qcom: icc-bwmon: corrige el desequilibrio de recuento visto durante bwmon_remove La siguiente advertencia se ve durante bwmon_remove debido a un desequilibrio de recuento; solucione esto liberando los OPP después de su uso. Registros: ADVERTENCIA: en drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Nombre del hardware: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Seguimiento de llamadas: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_ opp_of_table_release+ 0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 dispositivo_unbind_cleanup+0x18/0x60 dispositivo_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30 /0x60 plataforma_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon ] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13 c/0x158 el0t_64_sync+0x190/0x194 --[ final de seguimiento 0000000000000000 ]---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hwmon: (ltc2991) condiciones de reordenamiento para corregir un error LTC2991_T_INT_CH_NR es 4. La matriz st->temp_en[] tiene elementos LTC2991_MAX_CHANNEL (4). Por lo tanto, si "canal" es igual a LTC2991_T_INT_CH_NR entonces hemos leído un elemento más allá del final de la matriz. Cambie las condiciones para verificar si "canal" es válido antes de usarlo como índice de matriz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige el error de referencia nula al comprobar el final de la zona. Este parche corrige un puntero potencialmente nulo al que accede is_end_zone_blkaddr() que comprueba el último bloque de una zona cuando f2fs está montado como dispositivo único.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pdr: protege locator_addr con el mutex principal Si el servidor del localizador de servicios se reinicia lo suficientemente rápido, el PDR puede reescribir los campos locator_addr simultáneamente. Protéjalos colocando la modificación de esos campos bajo el pdr->lock principal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: xilinx: cambiar el nombre de cpu_number1 a dummy_cpu_number La variable por CPU cpu_number1 se pasa a xlnx_event_handler como argumento "dev_id", pero no se utiliza en esta función. Así que elimine la inicialización de esta variable y cámbiele el nombre a dummy_cpu_number. Este parche es para corregir el siguiente seguimiento de llamadas cuando la opción del kernel CONFIG_DEBUG_ATOMIC_SLEEP está habilitada: ERROR: función de suspensión llamada desde un contexto no válido en include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block : 0, pid: 1, nombre: swapper/0 preempt_count: 1, esperado: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Nombre de hardware: Xilinx Versal vmk180 Placa de evaluación rev1.1 (QSPI ) (DT) Seguimiento de llamadas: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/ 0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74 /0x138 xlnx_event_manager_probe+0xf8/0x298 plataforma_probe+0x68/0xd8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: Prevenir UAF en proc_cpuset_show() Puede ocurrir un UAF cuando se lee /proc/cpuset como se informa en [1]. Esto se puede reproducir mediante los siguientes métodos: 1.Agregue un mdelay(1000) antes de adquirir cgroup_lock en la función cgroup_path_ns. 2.$cat /proc//cpuset repetidamente. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repetidamente. La ejecución que causa este error se puede mostrar a continuación: (umount) | (cat /proc//cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsistemas | cgroup_free_root | | // cgrp fue liberado, UAF | cgroup_path_ns_locked(cgrp,..); Cuando se inicializa cpuset, el nodo raíz top_cpuset.css.cgrp apuntará a &cgrp_dfl_root.cgrp. En cgroup v1, la operación de montaje asignará cgroup_root y top_cpuset.css.cgrp apuntará al &cgroup_root.cgrp asignado. Cuando se ejecuta la operación desmontaje, top_cpuset.css.cgrp se rebotará en &cgrp_dfl_root.cgrp. El problema es que al volver a vincular a cgrp_dfl_root, hay casos en los que el cgroup_root asignado al configurar la raíz para cgroup v1 se almacena en caché. Esto podría dar lugar a un use-after-free (UAF) si se libera posteriormente. Los cgroups descendientes de cgroup v1 solo se pueden liberar después de que se publique el CSS. Sin embargo, el CSS de la raíz nunca se liberará, pero cgroup_root debe liberarse cuando se desmonta. Esto significa que obtener una referencia al CSS de la raíz no garantiza que css.cgrp->root no se libere. Solucione este problema usando rcu_read_lock en proc_cpuset_show(). Como cgroup_root es kfree_rcu después del commit d23b5c577715 ("cgroup: hacer que las operaciones en la RCU cgroup root_list sean seguras"), css->cgroup no se liberará durante la sección crítica. Para llamar a cgroup_path_ns_locked, se necesita css_set_lock, por lo que es seguro reemplazar task_get_css con task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: inicializa el búfer de integridad a cero antes de escribirlo en el medio. Los metadatos agregados por bio_integrity_prep utilizan kmalloc simple, lo que lleva a que la memoria del kernel se escriba en el medio de forma aleatoria. Para los metadatos de PI, esto se limita a la etiqueta de la aplicación que no es utilizada por los metadatos generados por el kernel, pero para los metadatos que no son de PI, todo el búfer pierde memoria del kernel. Solucione este problema agregando el indicador __GFP_ZERO a las asignaciones para escrituras.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: corrige el punto muerto entre mddev_suspend y purgar bio. El punto muerto ocurre cuando mddev se suspende mientras se realiza algún purga de biografía. Es una cuestión compleja. T1. la primera descarga está en la etapa final, borra 'mddev->flush_bio' e intenta enviar datos, pero se bloquea porque T4 suspende mddev. T2. la segunda descarga establece 'mddev->flush_bio' e intenta poner en cola md_submit_flush_data(), que ya se está ejecutando (T1) y no se ejecutará nuevamente si está en la misma CPU que T1. T3. el tercer enjuague incluye active_io e intenta descargar, pero se bloquea porque 'mddev->flush_bio' no es NULL (establecido por T2). T4. Se llama a mddev_suspend() y espera que active_io dec a 0, que es incrementado por T3. T1 T2 T3 T4 (flush 1) (flush 2) (tercero 3) (suspender) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request. mddev->flush_bio = biografía. cola submit_flushes . . . . md_handle_request. . activo_io + 1. . md_flush_request. . ¡espera! mddev->flush_bio. . . . mddev_suspend. . ¡espera! active_io. . . enviar_flushes. queue_work md_submit_flush_data. //md_submit_flush_data ya se está ejecutando (T1). md_handle_request espera reanudar la raíz del problema es el aumento/disminución no atómico de active_io durante el proceso de descarga. active_io disminuye antes de que md_submit_flush_data se ponga en cola y se inc poco después de ejecutar md_submit_flush_data(). md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 Si active_io se dec después de md_handle_request() en lugar de dentro de submit_flushes(), se puede llamar a make_request() directamente en lugar de md_handle_request() en md_submit_flush_data(), y active_io solo aumentará y disminuirá una vez durante todo el proceso de descarga. Se solucionará el punto muerto. Además, la única diferencia entre solucionar el problema y antes es que no hay manejo de errores de devolución de make_request(). Pero después de que el parche anterior limpió md_write_start(), make_requst() solo devuelve un error en raid5_make_request() por dm-raid, consulte el commit 41425f96d7aa ("dm-raid456, md/raid456: solucione un punto muerto para dm-raid456 mientras io concurre con reshape) ". Dado que dm siempre divide los datos y la operación de descarga en dos io separados, el tamaño de io de descarga enviado por dm siempre es 0, no se llamará a make_request() en md_submit_flush_data(). Para evitar que modificaciones futuras introduzcan problemas, agregue WARN_ON para garantizar que make_request() no se devuelva ningún error en este contexto.