Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: timers/migration: Fix another race between hotplug and idle entry/exit (temporizadores/migración: Arreglar otra ejecución entre hotplug y entrada/salida inactiva) Antes de adjuntar una nueva raíz a la raíz anterior, se comprueba el contador de hijos de la nueva raíz para verificar que solo el grupo superior de la próxima CPU se haya conectado a ella. Sin embargo, desde el commit b729cc1ec21a agregada recientemente ("timers/migration: Fix another race between hotplug and idle entry/exit"), esta comprobación ya no es válida porque la raíz anterior se contabiliza previamente como un hijo de la nueva raíz. Por lo tanto, después de conectar el grupo superior de la próxima CPU a la nueva raíz, el recuento de hijos que se espera debe ser 2 y no 1. Esta omisión da como resultado que la raíz anterior no se conecte a la nueva raíz. Luego, eventualmente, el sistema puede ejecutarse con más de un nivel superior, lo que frustra el propósito de un solo migrador inactivo. Además, la raíz anterior se contabiliza previamente pero no se conecta al momento de la creación de la nueva raíz. Pero se puede conectar a la nueva raíz más adelante. Por lo tanto, la raíz antigua puede contabilizarse dos veces para la nueva raíz. La propagación de dicha sobreasignación puede terminar creando una raíz de nivel superior final doble con una máscara de grupo inicializada incorrectamente. Aunque es inofensiva dado que las raíces de nivel superior finales nunca tendrán un padre al que llegar, esta rareza informó oportunistamente el problema principal: ADVERTENCIA: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt Solucione el problema teniendo en cuenta la raíz antigua en el recuento de hijos de la nueva raíz para que no se omita la conexión. También advierta cuando exista más de un grupo de nivel superior para detectar mejor problemas similares en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rxrpc, afs: Fix peer hash blocking vs RCU callback En su lista de direcciones, afs ahora retiene punteros y referencias en uno o más objetos rxrpc_peer. La lista de direcciones se libera bajo RCU y en este momento, pone las referencias en esos pares. Ahora, cuando un objeto rxrpc_peer se queda sin referencias, se elimina de la tabla hash de pares y, para eso, rxrpc tiene que tomar un spinlock. Sin embargo, ahora se está llamando desde la limpieza RCU de afs, que tiene lugar en el contexto BH, pero solo está tomando un spinlock ordinario. La put también se puede llamar desde un contexto que no sea BH, por lo que existe la posibilidad de un punto muerto si la limpieza RCU basada en BH ocurre mientras se mantiene el spinlock hash. Esto condujo a la queja adjunta lockdep. Solucione esto cambiando los spinlocks de rxnet->peer_hash_lock nuevamente a bloqueos que deshabilitan BH. ================================= ADVERTENCIA: estado de bloqueo inconsistente 6.13.0-rc5-build2+ #1223 Tainted: G E -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810babe228 (&rxnet->peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180 {SOFTIRQ-ON-W} state was registered at: mark_usage+0x164/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_peer_keepalive_worker+0x144/0x440 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x19b/0x1b0 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 irq event stamp: 972402 hardirqs last enabled at (972402): [] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [] _raw_spin_lock_irqsave+0x18/0x60 softirqs last enabled at (972300): [] handle_softirqs+0x3ee/0x430 softirqs last disabled at (972313): [] __irq_exit_rcu+0x44/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->peer_hash_lock); lock(&rxnet->peer_hash_lock); *** DEADLOCK *** 1 lock held by swapper/1/0: #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30 stack backtrace: CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223 Tainted: [E]=UNSIGNED_MODULE Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x57/0x80 print_usage_bug.part.0+0x227/0x240 valid_state+0x53/0x70 mark_lock_irq+0xa5/0x2f0 mark_lock+0xf7/0x170 mark_usage+0xe1/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_put_peer+0xcb/0x180 afs_free_addrlist+0x46/0x90 [kafs] rcu_do_batch+0x2d2/0x640 rcu_core+0x2f7/0x350 handle_softirqs+0x1ee/0x430 __irq_exit_rcu+0x44/0x110 irq_exit_rcu+0xa/0x30 sysvec_apic_timer_interrupt+0x7f/0xa0

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]

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: 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: 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: 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: 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.

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