Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: HWS, corrige la macro HWS_SET32 del definidor para desplazamiento negativo Cuando el desplazamiento de bits para la macro HWS_SET32 es negativo, UBSAN se queja del desplazamiento fuera de los límites: UBSAN: desplazamiento fuera de los límites en drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2 el exponente de desplazamiento -8 es negativo

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: Se corrigen advertencias durante la suspensión de S3 La función enable_gpe_wakeup() llama a acpi_enable_all_wakeup_gpes(), y la última puede llamar a la función preempt_schedule_common(), lo que da como resultado un cambio de hilo y hace que la CPU esté en un estado de interrupción habilitada después de que la función enable_gpe_wakeup() regrese, lo que genera las advertencias siguientes. [ C0] ADVERTENCIA: ... en kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Dado que ya no hay ejecución simultánea durante loongarch_acpi_suspend(), podemos llamar a acpi_hw_enable_all_wakeup_gpes() directamente en enable_gpe_wakeup(). La solución es similar a el commit 22db06337f590d01 ("ACPI: sleep: evitar interrumpir la activación de S3 debido a might_sleep()").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ravb: Se corrige el bloqueo rtnl faltante en la ruta de suspensión/reanudación Corrija la ruta de suspensión/reanudación asegurándose de que el bloqueo rtnl se mantenga donde sea necesario. Las llamadas a las operaciones ravb_open, ravb_close y wol se deben realizar bajo el bloqueo rtnl para evitar conflictos con las operaciones ndo en curso. Sin esta corrección, se activa la siguiente advertencia: [ 39.032969] ============================= [ 39.032983] ADVERTENCIA: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mailbox: th1520: Se corrige un error de NULL frente a IS_ERR() La función devm_ioremap() no devuelve punteros de error, sino NULL. Actualice la comprobación de errores para que coincida.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rhashtable: corrige un posible punto muerto moviendo schedule_work fuera del bloqueo Mueva la comprobación del crecimiento de la tabla hash y la programación del trabajo fuera del bloqueo rht para evitar una posible dependencia de bloqueo circular. La implementación original podría activar una advertencia de lockdep debido a un posible escenario de punto muerto que involucra bloqueos anidados entre el depósito rhashtable, el bloqueo rq y el bloqueo dsq. Al reubicar la comprobación del crecimiento y la programación del trabajo después de liberar el bloqueo rth, rompemos esta posible cadena de punto muerto. Este cambio expande la flexibilidad de rhashtable al eliminar el bloqueo restrictivo que anteriormente limitaba su uso en contextos de planificador y cola de trabajo. Importe para decir que esto llama a rht_grow_above_75(), que lee desde struct rhashtable sin mantener el bloqueo, si esto es un problema, podemos mover la comprobación al bloqueo y programar la cola de trabajo después del bloqueo. Modificado para que atomic_inc también se mueva fuera del bloqueo del depósito junto con la verificación de crecimiento por encima del 75%.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firewire: test: Se corrige una posible desreferencia nula en la prueba kunit de firewire kunit_kzalloc() puede devolver un puntero NULL, desreferenciarlo sin la comprobación NULL puede provocar una desreferencia NULL. Se añade una comprobación NULL para test_state.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: arreglo de liberación de IRQ en am65_cpsw_nuss_remove_tx_chns() Al obtener la IRQ, usamos k3_udma_glue_tx_get_irq() que devuelve un valor de error negativo en caso de error. Por lo tanto, la comprobación de que no sea NULL no es suficiente para determinar si la IRQ es válida. Compruebe que la IRQ sea mayor que cero para asegurarse de que sea válida. No hay ningún problema en el momento de la prueba, pero en el momento de la ejecución, el usuario puede invocar .set_channels, lo que da como resultado la siguiente cadena de llamadas. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() En este punto, si am65_cpsw_nuss_init_tx_chns() falla debido a k3_udma_glue_tx_get_irq(), tx_chn->irq se establecerá en un valor negativo. Luego, en los .set_channels posteriores con un mayor conteo de canales, intentaremos liberar una IRQ no válida en am65_cpsw_nuss_remove_tx_chns(), lo que generará una advertencia del kernel. El problema está presente en el commit original que introdujo este controlador, aunque allí, am65_cpsw_nuss_update_tx_rx_chns() existía como am65_cpsw_nuss_update_tx_chns().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: se corrige el error al descargar controladores en paralelo. Al descargar el controlador hclge, primero intenta deshabilitar sriov para cada nodo ae_dev de hnae3_ae_dev_list. Si el usuario descarga el controlador hns3 en ese momento, debido a que elimina todos los nodos ae_dev, y puede causar errores. Pero no podemos simplemente usar hnae3_common_lock para esto. Porque en el flujo de proceso de pci_disable_sriov(), activará el flujo de eliminación de VF, que también tomará hnae3_common_lock. Para solucionarlo, introduzca un nuevo mutex para proteger el proceso de descarga.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memoria: tegra20-emc: se corrige un error de referencia de nodo OF en tegra_emc_find_node_by_ram_code() Como of_find_node_by_name() libera la referencia del nodo de dispositivo de argumento, tegra_emc_find_node_by_ram_code() libera algunos nodos de dispositivo mientras aún están en uso, lo que da como resultado posibles UAF. Según los enlaces y los archivos DTS en el árbol, el nodo "emc-tables" siempre es el nodo secundario del dispositivo con la propiedad "nvidia,use-ram-code", y el nodo "lpddr2" es un nodo secundario del nodo "emc-tables". Por lo tanto, utilice la macro for_each_child_of_node() y of_get_child_by_name() en lugar de of_find_node_by_name() para simplificar el código. Este error fue encontrado por una herramienta de verificación experimental que estoy desarrollando. [krzysztof: se aplicó la versión 1, se ajustó el mensaje de confirmación para incorporar partes de la versión 2]

Se descubrió que AVE System Web Client v2.1.131.13992 contenía una vulnerabilidad de cross-site scripting (XSS).

Se descubrió un problema en los dispositivos Tuoshi/Dionlink LT15D 4G Wi-Fi a través de M7628NNxlSPv2xUI_v1.0.1802.10.08_P4 y en los dispositivos LT21B a través de M7628xUSAxUIv2_v1.0.1481.15.02_P0. Un atacante remoto no autenticado con acceso a la red puede aprovechar una vulnerabilidad de inyección de comandos. El endpoint /goform/formJsonAjaxReq no pueden depurar los metacaracteres del shell enviados a través de parámetros JSON, lo que permite a los atacantes ejecutar comandos arbitrarios del sistema operativo con privilegios de superusuario.

Nagios XI 2024R1.2.2 es vulnerable a una falla de redirección abierta en la página Herramientas, que pueden aprovechar los usuarios con permisos de solo lectura. Esta vulnerabilidad permite a un atacante manipular un enlace malicioso que redirige a los usuarios a una URL externa arbitraria sin su consentimiento.