Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: convertir colas de trabajo en no vinculadas Cuando se crea una cola de trabajo con `WQ_UNBOUND`, sus elementos de trabajo son atendidos por grupos de trabajadores especiales, cuyos trabajadores host no están vinculados a ninguna CPU específica. En la configuración predeterminada (es decir, cuando `queue_delayed_work` y amigos no especifican en qué CPU ejecutar el elemento de trabajo), `WQ_UNBOUND` permite que el elemento de trabajo se ejecute en cualquier CPU en el mismo nodo de la CPU en la que se puso en cola. Si bien esta solución potencialmente sacrifica la localidad, evita la contención con otros procesos que podrían dominar el tiempo de CPU del procesador en el que se programó el elemento de trabajo. Este no es solo un problema teórico: en un escenario particular, el proceso mal configurado acaparaba la mayor parte del tiempo de la CPU0, dejando menos del 0,5% de su tiempo de CPU al kworker. Las colas de trabajo IDPF que estaban usando el kworker en CPU0 sufrieron grandes retrasos en la finalización como resultado, causando degradación del rendimiento, tiempos de espera y eventualmente falla del sistema. * También he ejecutado una prueba manual para medir la mejora del rendimiento. La prueba consiste en un proceso antagonista (`./stress --cpu 2`) que consume la mayor cantidad posible de CPU 0. Este proceso se ejecuta bajo `taskset 01` para vincularlo a CPU0, y su prioridad se cambia con `chrt -pQ 9900 10000 ${pid}` y `renice -n -20 ${pid}` después del inicio. Luego, el controlador IDPF se ve obligado a preferir CPU0 editando todas las llamadas a `queue_delayed_work`, `mod_delayed_work`, etc... para usar CPU 0. Finalmente, se recopilan `ktraces` para los eventos de la cola de trabajo. Sin el parche actual, el proceso antagonista puede forzar demoras arbitrarias entre `workqueue_queue_work` y `workqueue_execute_start`, que en mis pruebas fueron tan altas como `30ms`. Con el parche actual aplicado, la cola de trabajo se puede migrar a otra CPU sin carga en el mismo nodo y, manteniendo todo lo demás igual, la demora máxima que pude ver fue `6us`.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc: Se ha corregido la gestión de la interrupción de la conexión recibida Se ha corregido la gestión de una interrupción de la conexión que hemos recibido. Aunque la interrupción se produce a nivel de conexión, es necesario propagarla a las llamadas de esa conexión. Mientras se realiza el bit de propagación, las llamadas no se activan para procesar su finalización y, como no se recibe ninguna otra entrada, simplemente se cuelgan. También se ha añadido algún seguimiento para el registro de las interrupciones de la conexión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: media: max96712: arregla el error del kernel al eliminar el módulo El siguiente error del kernel se produce al intentar eliminar el módulo max96712: No se puede gestionar la solicitud de paginación del kernel en la dirección virtual 00007375746174db Información de aborto de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]--- Esto sucede porque en v4l2_i2c_subdev_init(), se vuelve a llamar a i2c_set_cliendata() y los datos se sobrescriben para apuntar a sd, en lugar de priv. Entonces, en remove(), se pasa el puntero incorrecto a v4l2_async_unregister_subdev(), lo que genera un bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipmi: ipmb: Agregar verificación del valor devuelto por devm_kasprintf() devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto no se verifica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: Arreglar posible desreferencia de puntero NULL en atomctrl_get_smc_sclk_range_table La función atomctrl_get_smc_sclk_range_table() no comprueba el valor de retorno de smu_atom_get_data_table(). Si smu_atom_get_data_table() no puede recuperar la tabla SMU_Info, devuelve NULL que luego se desreferencia. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE. En la práctica, esto nunca debería suceder ya que este código solo se llama en chips polaris y la tabla de datos vbios siempre estará presente en esos chips.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_tcm: No libere el comando inmediatamente No libere el comando de forma prematura. Espere a que se complete el estado de detección. En ese momento, se puede liberar. De lo contrario, liberaremos el comando dos veces.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: remoteproc: core: Se corrige en ida_free call while not allocated In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called. In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc Llamar a ida_alloc antes en rproc_alloc garantiza que rproc->index está configurado correctamente.

Se encontró una vulnerabilidad en Seeyon Zhiyuan Interconnect FE Collaborative Office Platform hasta 20250224. Se ha calificado como crítica. Este problema afecta a algunas funciones desconocidas del archivo /security/addUser.jsp. La manipulación del argumento groupId conduce a una inyección SQL. 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.

Un problema en TAAGSOLUTIONS GmbH MyTaag v.2024-11-24 y anteriores permite que un atacante remoto escale privilegios a través del endpoint "/user"

Un problema en TAAGSOLUTIONS GmbH MyTaag v.2024-11-24 y anteriores permite que un atacante físicamente próximo escale privilegios a través de la clave de almacenamiento local "2fa_authorized"

Un problema en TAAGSOLUTIONS GmbH MyTaag v.2024-11-24 y anteriores permite que un atacante remoto escale privilegios a través de la desactivación del segundo factor activado al endpoint /session

Se ha detectado una vulnerabilidad en MicroDicom DICOM Viewer 2025.1 Build 3321. Se ha clasificado como crítica. Se ve afectada una función desconocida del archivo mDicom.exe. La manipulación provoca la corrupción de la memoria. El ataque debe abordarse localmente. Se recomienda actualizar el componente afectado. El proveedor confirmó rápidamente la existencia de la vulnerabilidad y la corrigió en la última versión beta.