Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar smcd_v2_ext_offset al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, el campo smcd_v2_ext_offset en el mensaje de propuesta es del cliente remoto y no se puede confiar completamente en él. Una vez que el valor de smcd_v2_ext_offset excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede ocurrir un bloqueo. Este parche verifica el valor de smcd_v2_ext_offset antes de usarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dlm: arregla posible desreferencia nula de lkb_resource Este parche corrige una posible desreferencia de puntero nulo cuando se llama a esta función desde request_lock() ya que lkb->lkb_resource aún no está asignado, solo después de validar_lock_args() llamando a attached_lkb(). Otro problema es que un nombre de recurso podría ser un bytearray no imprimible y no podemos asumir que esté codificado en ASCII. Es probable que la funcionalidad de registro nunca se vea afectada cuando se usa DLM de forma normal y no se habilita ningún registro de depuración. La desreferencia de puntero nulo solo puede ocurrir en un lkb creado recientemente que aún no tenga el recurso asignado, probablemente nunca llegue a la desreferencia de puntero nulo, pero debemos estar seguros de que otros cambios podrían no cambiar este comportamiento y realmente podemos llegar a la desreferencia de puntero nulo mencionada. En este parche simplemente omitimos la impresión del nombre del recurso, el id de lkb es suficiente para hacer una posible conexión con un nombre de recurso si existe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para reducir el nodo de extensión de lectura en lotes Usamos rwlock para proteger los datos de la estructura central del árbol de extensión durante su reducción, sin embargo, si hay una gran cantidad de nodos de extensión en el árbol de extensión, durante la reducción del árbol de extensión, puede mantener rwlock durante mucho tiempo, lo que puede desencadenar un problema de bloqueo del kernel. Este parche corrige la reducción del nodo de extensión de lectura en lotes, de modo que la región crítica de rwlock se pueda reducir para evitar su retención de tiempo extremadamente largo.

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.