Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinmux: usar acceso secuencial para acceder a los datos de desc->pinmux Cuando dos clientes del mismo gpio llaman a pinctrl_select_state() para la misma funcionalidad, vemos un problema de puntero NULL al acceder a desc->mux_owner. Digamos que dos procesos A, B se ejecutan en pin_request() para el mismo pin y el proceso A actualiza desc->mux_usecount pero aún no actualiza desc->mux_owner mientras que el proceso B ve desc->mux_usecount que fue actualizado por la ruta A y luego ejecuta strcmp y mientras accede a desc->mux_owner se bloquea con el puntero NULL. Serialice el acceso a la configuración relacionada con mux con un bloqueo de mutex. cpu0 (proceso A) cpu1 (proceso B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } de lo contrario { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, propietario)) { si (desc->mux_usecount > 1) devuelve 0; desc->mux_owner = propietario; } }

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: Use i3cdev->desc->info en lugar de llamar a i3c_device_get_info() para evitar un bloqueo. Puede ocurrir un bloqueo porque i3c_master_register() adquiere &i3cbus->lock dos veces. Vea el registro a continuación. Use i3cdev->desc->info en lugar de llamar a i3c_device_info() para evitar adquirir el bloqueo dos veces. v2: - Se modificaron el título y el mensaje de confirmación ============================================= ADVERTENCIA: se detectó un posible bloqueo recursivo 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i3c: mipi-i3c-hci: Enmascarar interrupciones del anillo antes de la solicitud de detención del anillo La ruta de desinfección del bus en modo DMA puede activar una interrupción RING_OP_STAT cuando se detiene el anillo. Dependiendo del tiempo entre la finalización de la solicitud de detención del anillo, la eliminación del controlador de interrupciones y la ejecución del código, esto puede provocar una desreferencia de puntero NULL en hci_dma_irq_handler() si se ejecuta después de que el puntero io_data se establezca en NULL en hci_dma_cleanup(). Evite esto enmascarando las interrupciones del anillo antes de la solicitud de detención del anillo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: no acceder a sched no válido Desde 2320c9e6a768 ("drm/sched: memset() 'job' en drm_sched_job_init()") acceder a job->base.sched puede producir resultados inesperados ya que la inicialización de (*job)->base.sched realizada en amdgpu_job_alloc es sobrescrita por memset. Esta confirmación corrige un problema cuando un CS fallaría la validación y sería rechazado después de que se incremente job->num_ibs. En este caso, se llamará a amdgpu_ib_free(ring->adev, ...), lo que bloquearía la máquina porque el valor de ring es falso. Para corregir esto, pase un puntero NULL a amdgpu_ib_free(): podemos hacer esto porque el dispositivo en realidad no se usa en esta función. La próxima confirmación eliminará el argumento ring por completo. (seleccionado del commit 2ae520cb12831d264ceb97c61f72c59d33c0dbd7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched: corrección de advertencia en sched_setaffinity El commit 8f9ea86fdf99b agregó algo de lógica a sched_setaffinity que incluía una ADVERTENCIA cuando una asignación de afinidad por tarea compite con una actualización de cpuset. Específicamente, podemos tener una ejecución donde una actualización de cpuset da como resultado que la afinidad de la tarea ya no sea un subconjunto del cpuset. Eso está bien; tenemos una alternativa para usar la máscara de cpuset. Sin embargo, tenemos una ADVERTENCIA configurada que se activará si la máscara de cpuset no se superpone en absoluto con la afinidad de la tarea solicitada. Esto no debería ser una condición de advertencia; es trivial crear esta condición. Se reprodujo la advertencia con la siguiente configuración: - $PID dentro de un cgroup de cpuset - otro hilo que cambia repetidamente las CPU de cpuset de 1-2 a solo 1 - otro hilo que establece repetidamente la afinidad $PID (a través del conjunto de tareas) en 2

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: evitar reutilizar `hctx` no eliminado de la lista de devolución de llamadas de cpuhp Si 'hctx' no se elimina de la lista de devolución de llamadas de cpuhp, no podemos reutilizarlo, de lo contrario, se puede activar el use after free.

Se ha encontrado una vulnerabilidad clasificada como crítica en Guangzhou Huayi Intelligent Technology Jeewms hasta 20241229. La función datagridGraph del archivo /graphReportController.do está afectada. La manipulación del argumento store_code provoca una inyección SQL. Es posible lanzar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse. La actualización a la versión 20250101 puede solucionar este problema. Se recomienda actualizar el componente afectado.

Se ha encontrado una vulnerabilidad, que se ha clasificado como crítica, en Guangzhou Huayi Intelligent Technology Jeewms hasta 20241229. Este problema afecta a la función saveOrUpdate del archivo org/jeecgframework/web/cgform/controller/build/CgFormBuildController.java. La manipulación conduce a una inyección SQL. El ataque puede iniciarse de forma remota. El exploit se ha divulgado al público y puede utilizarse. La actualización a la versión 20250101 puede solucionar este problema. Se recomienda actualizar el componente afectado.

HCL MyXalytics se ve afectada por una vulnerabilidad de validación de entrada débil. La aplicación acepta caracteres especiales y no hay validación de longitud. Esto puede generar vulnerabilidades de seguridad como inyección SQL, XSS y desbordamiento de búfer.

Se ha encontrado una vulnerabilidad clasificada como crítica en Guangzhou Huayi Intelligent Technology Jeewms hasta 20241229. Esta vulnerabilidad afecta al código desconocido del archivo /wmOmNoticeHController.do. La manipulación conduce a la navegación por la ruta: '../filedir'. El ataque se puede iniciar de forma remota. El exploit se ha hecho público y puede utilizarse. La actualización a la versión 20250101 puede solucionar este problema. Se recomienda actualizar el componente afectado.

El complemento GiveWP – Donation Plugin and Fundraising Platform para WordPress es vulnerable a la inyección de objetos PHP en todas las versiones hasta la 3.19.2 incluida, a través de la deserialización de datos no confiables del formulario de donación, como "firstName". Esto permite que atacantes no autenticados inyecten un objeto PHP. La presencia adicional de una cadena POP permite a los atacantes eliminar archivos arbitrarios en el servidor, lo que hace posible la ejecución remota de código. Tenga en cuenta que esto solo se solucionó parcialmente en la versión 3.19.3; no se lanzó un parche completamente suficiente hasta la versión 3.19.4. Sin embargo, otro CNA asignó otra CVE para la versión 3.19.3, por lo que dejaremos que esto afecte a la versión 3.19.2 y anteriores. Hemos recomendado al proveedor que utilice codificación JSON para evitar que se presenten más vulnerabilidades de deserialización.

El complemento Push Notification for Post y BuddyPress para WordPress es vulnerable a ataques de Cross Site Scripting reflejado a través del parámetro 'pushnotificationid' en todas las versiones hasta la 2.06 incluida, debido a una desinfección de entrada y un escape de salida insuficientes. Esto permite que atacantes no autenticados inyecten web scripts arbitrarios en páginas que se ejecutan si logran engañar a un usuario para que realice una acción, como hacer clic en un enlace.