Vulnerabilidades

Una desreferencia de puntero NULL en los dispositivos Draytek Vigor 165/166 anteriores a v4.2.6, Vigor 2620/LTE200 anteriores a v3.9.8.8, Vigor 2860/2925 anteriores a v3.9.7, Vigor 2862/2926 anteriores a v3.9.9.4, Vigor 2133/2762/2832 anteriores a v3.9.8, Vigor 2135/2765/2766 anteriores a v4.4.5.1, Vigor 2865/2866/2927 anteriores a v4.4.5.3, Vigor 2962/3910 anteriores a v4.3.2.7, Vigor 3912 anteriores a v4.3.5.2 y Vigor 2925 hasta v3.9.6 permite a los atacantes provocar una denegación de servicio (DoS) a través de una solicitud DHCP manipulada específicamente.

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: 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: mm/compaction: se corrige la advertencia de cambio fuera de los límites de UBSAN syzkaller informó una advertencia de cambio fuera de los límites de UBSAN de (1UL << order) en isolate_freepages_block(). El compuesto falso puede ser cualquier valor porque es una unión con indicadores. Vuelva a agregar la verificación MAX_PAGE_ORDER para corregir la advertencia.

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: block: mark GFP_NOIO around sysfs ->store() sysfs ->store se llama con la cola congelada, mientras tanto tenemos varias devoluciones de llamadas ->store() (update_nr_requests, wbt, scheduler) para asignar memoria con GFP_KERNEL que puede ejecutarse en una ruta de código de recuperación directa, lo que puede provocar un posible bloqueo. Solucione el problema marcando NOIO alrededor de sysfs ->store()

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: 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: ptp: vmclock: Establecer datos del controlador antes de su uso Si vmclock_ptp_register() falla durante el sondeo, se llama a vmclock_remove() para limpiar el reloj ptp y el dispositivo misceláneo. Utiliza dev_get_drvdata() para acceder al estado de vmclock. Sin embargo, los datos del controlador aún no están establecidos en este punto. Asigne los datos del controlador antes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/xen: se ha corregido xen_hypercall_hvm() para que no bloquee %rbx xen_hypercall_hvm(), que se utiliza cuando se ejecuta como invitado PVH de Xen como máximo una vez durante el arranque inicial, está bloqueando %rbx. Dependiendo de si el autor de la llamada confía en que %rbx se conserve durante la llamada o no, esta obstrucción puede provocar un bloqueo temprano del sistema. Esto se puede evitar utilizando un registro ya guardado en lugar de %rbx.

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: gpu: host1x: Fix a use of uninitialized mutex commit c8347f915e67 ("gpu: host1x: Fix boot regression for Tegra") provocó el uso de un mutex no inicializado que generó la siguiente advertencia cuando CONFIG_DEBUG_MUTEXES y CONFIG_DEBUG_LOCK_ALLOC están habilitados. [ 41.662843] ------------[ cortar aquí ]------------ [ 41.663012] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 41.663035] WARNING: CPU: 4 PID: 794 at kernel/locking/mutex.c:587 __mutex_lock+0x670/0x878 [ 41.663458] Modules linked in: rtw88_8822c(+) bluetooth(+) rtw88_pci rtw88_core mac80211 aquantia libarc4 crc_itu_t cfg80211 tegra194_cpufreq dwmac_tegra(+) arm_dsu_pmu stmmac_platform stmmac pcs_xpcs rfkill at24 host1x(+) tegra_bpmp_thermal ramoops reed_solomon fuse loop nfnetlink xfs mmc_block rpmb_core ucsi_ccg ina3221 crct10dif_ce xhci_tegra ghash_ce lm90 sha2_ce sha256_arm64 sha1_ce sdhci_tegra pwm_fan sdhci_pltfm sdhci gpio_keys rtc_tegra cqhci mmc_core phy_tegra_xusb i2c_tegra tegra186_gpc_dma i2c_tegra_bpmp spi_tegra114 dm_mirror dm_region_hash dm_log dm_mod [ 41.665078] CPU: 4 UID: 0 PID: 794 Comm: (udev-worker) Not tainted 6.11.0-29.31_1538613708.el10.aarch64+debug #1 [ 41.665838] Hardware name: NVIDIA NVIDIA Jetson AGX Orin Developer Kit/Jetson, BIOS 36.3.0-gcid-35594366 02/26/2024 [ 41.672555] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 41.679636] pc : __mutex_lock+0x670/0x878 [ 41.683834] lr : __mutex_lock+0x670/0x878 [ 41.688035] sp : ffff800084b77090 [ 41.691446] x29: ffff800084b77160 x28: ffffdd4bebf7b000 x27: ffffdd4be96b1000 [ 41.698799] x26: 1fffe0002308361c x25: 1ffff0001096ee18 x24: 0000000000000000 [ 41.706149] x23: 0000000000000000 x22: 0000000000000002 x21: ffffdd4be6e3c7a0 [ 41.713500] x20: ffff800084b770f0 x19: ffff00011841b1e8 x18: 0000000000000000 [ 41.720675] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 41.728023] x14: 0000000000000000 x13: 0000000000000001 x12: ffff6001a96eaab3 [ 41.735375] x11: 1fffe001a96eaab2 x10: ffff6001a96eaab2 x9 : ffffdd4be4838bbc [ 41.742723] x8 : 00009ffe5691554e x7 : ffff000d4b755593 x6 : 0000000000000001 [ 41.749985] x5 : ffff000d4b755590 x4 : 1fffe0001d88f001 x3 : dfff800000000000 [ 41.756988] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000ec478000 [ 41.764251] Call trace: [ 41.766695] __mutex_lock+0x670/0x878 [ 41.770373] mutex_lock_nested+0x2c/0x40 [ 41.774134] host1x_intr_start+0x54/0xf8 [host1x] [ 41.778863] host1x_runtime_resume+0x150/0x228 [host1x] [ 41.783935] pm_generic_runtime_resume+0x84/0xc8 [ 41.788485] __rpm_callback+0xa0/0x478 [ 41.792422] rpm_callback+0x15c/0x1a8 [ 41.795922] rpm_resume+0x698/0xc08 [ 41.799597] __pm_runtime_resume+0xa8/0x140 [ 41.803621] host1x_probe+0x810/0xbc0 [host1x] [ 41.807909] platform_probe+0xcc/0x1a8 [ 41.811845] really_probe+0x188/0x800 [ 41.815347] __driver_probe_device+0x164/0x360 [ 41.819810] driver_probe_device+0x64/0x1a8 [ 41.823834] __driver_attach+0x180/0x490 [ 41.827773] bus_for_each_dev+0x104/0x1a0 [ 41.831797] driver_attach+0x44/0x68 [ 41.835296] bus_add_driver+0x23c/0x4e8 [ 41.839235] driver_register+0x15c/0x3a8 [ 41.843170] __platform_register_drivers+0xa4/0x208 [ 41.848159] tegra_host1x_init+0x4c/0xff8 [host1x] [ 41.853147] do_one_initcall+0xd4/0x380 [ 41.856997] do_init_module+0x1dc/0x698 [ 41.860758] load_module+0xc70/0x1300 [ 41.864435] __do_sys_init_module+0x1a8/0x1d0 [ 41.868721] __arm64_sys_init_module+0x74/0xb0 [ 41.873183] invoke_syscall.constprop.0+0xdc/0x1e8 [ 41.877997] do_el0_svc+0x154/0x1d0 [ 41.881671] el0_svc+0x54/0x140 [ 41.884820] el0t_64_sync_handler+0x120/0x130 [ 41.889285] el0t_64_sync+0x1a4/0x1a8 [ 41.892960] irq event stamp: 69737 [ 41.896370] hardirqs last enabled at (69737): [] _raw_spin_unlock_irqrestore+0x44/0xe8 [ 41.905739] hardirqs last disabled at (69736): ---truncated---