Vulnerabilidades

elestio memos v0.23.0 es vulnerable a Server-Side Request Forgery (SSRF) debido a una validación insuficiente de las URL proporcionadas por el usuario, lo que puede explotarse para realizar ataques SSRF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hrtimers: fuerza la migración de los hrtimers en cola después de CPUHP_AP_HRTIMERS_DYING. Los hrtimers se migran desde la CPU que se está muriendo a cualquier destino en línea en la etapa CPUHP_AP_HRTIMERS_DYING para no retrasar las tareas de gestión de los temporizadores de ancho de banda involucradas en el progreso de avance de la conexión en caliente de la CPU. Sin embargo, las reactivaciones aún pueden ser realizadas por la CPU saliente después de CPUHP_AP_HRTIMERS_DYING. Esto puede dar como resultado nuevamente que los temporizadores de ancho de banda se activen. Dependiendo de varias consideraciones (elección basada en administración de energía de Crystal Ball, temporizador más antiguo ya en cola, migración de temporizador habilitada o no), el destino puede eventualmente ser la CPU actual incluso si está fuera de línea. Si eso sucede, el temporizador eventualmente se ignora. El ejemplo más notable es RCU, que tuvo que lidiar con todos y cada uno de esos despertares difiriéndolos a una CPU en línea, junto con workarounds relacionados: _ e787644caf76 (rcu: Diferir el despertar de kthreads de RCU cuando la CPU está muriendo) _ 9139f93209d1 (rcu/nocb: Reparar la limitación de RT de hrtimer armado desde una CPU fuera de línea) _ f7345ccc62a4 (rcu/nocb: Reparar el despertar de rcuog desde softirq fuera de línea) El problema no se limita a RCU, ya que el kthread de la máquina de detención (que ejecuta CPUHP_AP_HRTIMERS_DYING) informa su finalización al final de su trabajo a través de cpu_stop_signal_done() y realiza un despertar que eventualmente arma el temporizador del servidor de fecha límite: ADVERTENCIA: CPU: 94 PID: 588 en kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: immigration/94 No contaminado Detenedor: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0 RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0 Rastreo de llamadas: start_dl_timer enqueue_dl_entity dl_server_start enqueue_task_fair enqueue_task ttwu_do_activate try_to_wake_up complete cpu_stopper_thread En lugar de proporcionar otro workaround para solucionar la situación, corríjala en la infraestructura de hrtimers: siempre migre un temporizador a un destino en línea cuando se ponga en cola desde una CPU fuera de línea. Esto también permitirá revertir todos los vergonzosos hackeos de RCU mencionados anteriormente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir "drm/amd/display: Use HW lock mgr for PSR1" Esto revierte el commit a2b5a9956269 ("drm/amd/display: Use HW lock mgr for PSR1") porque puede provocar que el sistema se cuelgue al conectarse con dos paneles edp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: xilinx_uartps: la gestión dividido de sysrq lockdep detecta la siguiente dependencia de bloqueo circular: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. Sin embargo, si (como se muestra arriba) cdns_uart_console_write se ejecuta antes de que port->sysrq esté configurado, entonces intentará tomar el bloqueo del puerto de todos modos. Esto puede resultar en un bloqueo. Solucione esto dividiendo la gestión de sysrq en dos partes. Usamos el asistente de preparación bajo el bloqueo del puerto y posponemos la gestión hasta que liberemos el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: omap: usar IRQ enhebrado para DMA de LCD Al usar la pantalla táctil y el framebuffer, Nokia 770 se bloquea fácilmente con: ERROR: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28 Como solución rápida, cambie a una IRQ con subprocesos que proporcione un sistema estable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: eliminar un trabajador de métricas ELP no administrado El trabajador ELP necesita calcular nuevos valores de métricas para todos los vecinos "alcanzables" a través de una interfaz. Algunas de las fuentes de métricas utilizadas requieren bloqueos que podrían necesitar dormir. Esta suspensión es incompatible con el iterador de lista RCU utilizado para los vecinos registrados. El enfoque inicial para solucionar este problema fue poner en cola otro elemento de trabajo por vecino y luego ejecutarlo en un nuevo contexto. Incluso cuando esto resolvió el conflicto RCU vs might_sleep(), tiene un problema importante: nada detenía el elemento de trabajo en caso de que ya no fuera necesario, por ejemplo, porque se eliminó una de las interfaces relacionadas o se descargó el módulo batman-adv, lo que resultó en posibles accesos de memoria no válidos. Cancelar directamente el trabajador de métricas también tiene varios problemas: * cancel_work_sync para una interfaz que se desactivará se llama con rtnl_lock retenido. Pero el código en el trabajador de métricas ELP también intenta usar rtnl_lock() - que nunca regresará en este caso. Esto también significa que cancel_work_sync nunca regresaría porque está esperando que el trabajador termine. * iterar sobre la lista de vecinos para la interfaz que se va a desactivar se realiza actualmente utilizando los métodos específicos de RCU. Lo que significa que es posible omitir elementos al iterarla sin el spinlock asociado - un comportamiento que es aceptable para una verificación periódica de métricas pero no para una rutina de limpieza (que debe "detener" todos los trabajadores que aún se están ejecutando) El mejor enfoque es deshacerse del trabajador de métricas de vecinos por interfaz y manejar todo en el trabajador de interfaz. Los problemas originales se resuelven: * creando una lista de vecinos que requieren nueva información métrica dentro del contexto protegido de RCU, recopilando la métrica de acuerdo con la nueva lista fuera del contexto protegido de RCU * solo use rcu_trylock dentro del código de recopilación de métricas para evitar un bloqueo cuando se llama a cancel_delayed_work_sync en el código de eliminación de interfaz (que se llama con rtnl_lock retenido)

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: núcleo del controlador: clase: Arreglar desreferencias de punteros salvajes en la API class_dev_iter_next() Hay un posible problema de desreferencias de punteros salvajes con respecto a las API class_dev_iter_(init|next|exit()), como se explica a continuación en el uso típico: // Todos los miembros de @iter son punteros salvajes. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) comprueba el parámetro @class en busca de un posible error class_to_subsys(), y devuelve el tipo void y no inicializa su parámetro de salida @iter, por lo que el llamador no puede detectar el error y continúa invocando class_dev_iter_next(@iter) incluso si @iter todavía contiene punteros salvajes. class_dev_iter_init(&iter, ...); // Desreferencia estos punteros salvajes en @iter aquí una vez que sufre el error. mientras (dev = class_dev_iter_next(&iter)) { ... }; // También desreferencia estos punteros salvajes aquí. class_dev_iter_exit(&iter); En realidad, todos los que llaman a estas API tienen ese patrón de uso en el árbol del kernel. Solucione esto: - Inicialice el parámetro de salida @iter con memset() en class_dev_iter_init() y dé a los que llaman un aviso con pr_crit() para el error. - Verifique si @iter es válido en class_dev_iter_next().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: xdp: No permitir adjuntar programas vinculados al dispositivo en modo genérico Los programas vinculados al dispositivo se utilizan para admitir las kfuncs de metadatos RX. Estas kfuncs son específicas del controlador y dependen del contexto del controlador para leer los metadatos. Esto significa que no pueden funcionar en modo XDP genérico. Sin embargo, no hay ninguna verificación para no permitir que dichos programas se adjunten en modo genérico, en cuyo caso las kfuncs de metadatos se llamarán en un contexto no válido, lo que provocará fallas. Solucione esto agregando una verificación para no permitir adjuntar programas vinculados al dispositivo en modo genérico.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: block: fix queue freeze vs limits lock order in sysfs store methods queue_attr_store() siempre congela una cola de dispositivos antes de llamar a la operación de almacenamiento de atributos. Para los atributos que controlan los límites de la cola, la operación de almacenamiento también bloqueará los límites de la cola con una llamada a queue_limits_start_update(). Sin embargo, algunos controladores (por ejemplo, SCSI sd) pueden necesitar emitir comandos a un dispositivo para obtener valores límite del hardware con los límites de la cola bloqueados. Esto crea una posible situación de bloqueo ABBA si un usuario intenta modificar un límite (congelando así la cola del dispositivo) mientras el controlador del dispositivo inicia una revalidación de los límites de la cola del dispositivo. Evite dicho bloqueo al no congelar la cola antes de llamar al método ->store_limit() en struct queue_sysfs_entry y, en su lugar, utilice el asistente queue_limits_commit_update_frozen para congelar la cola después de tomar el bloqueo de los límites. Esto también elimina la posibilidad de tomar el bloqueo de sysfs para el método store_limit, ya que no protege nada aquí, pero crea aún más anidamiento. Con suerte, desaparecerá por completo de los métodos sysfs reales pronto. (registro de confirmación adaptado de un parche similar de Damien Le Moal)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rtrs: Agregar llamada deinit() faltante Se activa una advertencia al conectar y desconectar repetidamente rnbd: corrupción de list_add. prev->next debería ser next (ffff88800b13e480), pero era ffff88801ecd1338. (prev=ffff88801ecd1340). ADVERTENCIA: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0 Workqueue: ib_cm cm_work_handler [ib_cm] RIP: 0010:__list_add_valid_or_report+0x7f/0xa0 ? __list_add_valid_or_report+0x7f/0xa0 ib_register_event_handler+0x65/0x93 [ib_core] rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server] rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core] __alloc_path+0x46c/0x680 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] ? rcu_is_watching+0xd/0x40 ? __mutex_lock+0x312/0xcf0 ? get_or_create_srv+0xad/0x310 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server] ? __lock_release+0x1b1/0x2d0 cma_cm_event_handler+0x4a/0x1a0 [rdma_cm] cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm] cm_process_work+0x28/0x1a0 [ib_cm] ? _raw_spin_unlock_irq+0x2f/0x50 cm_req_handler+0x618/0xa60 [ib_cm] cm_work_handler+0x71/0x520 [ib_cm] Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introdujo un nuevo elemento .deinit pero nunca lo usó. Arréglelo invocando `deinit()` para anular el registro del controlador de eventos IB de manera adecuada.

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