Vulnerabilidades

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

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: PCI: rcar-ep: Se corrige la variable incorrecta utilizada al llamar a devm_request_mem_region(). rcar_pcie_parse_outbound_ranges() utiliza la macro devm_request_mem_region() para solicitar un recurso necesario. Luego, se utiliza una variable de cadena que se encuentra en la pila para almacenar un nombre de recurso calculado dinámicamente, que luego se pasa como uno de los argumentos de la macro. Esto puede provocar un comportamiento indefinido. Según el contenido actual de la memoria, las manifestaciones de los errores pueden variar. Una posible salida puede ser la siguiente: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : A veces, puede aparecer basura después de los dos puntos. En casos muy raros, si no se encuentra un terminador NULL en la memoria, el sistema puede bloquearse porque el iterador de cadena se desbordará, lo que puede provocar el acceso a la memoria no asignada por encima de la pila. Por lo tanto, solucione este problema reemplazando outbound_name con el nombre del recurso solicitado anteriormente. Con los cambios aplicados, el resultado será el siguiente: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 [kwilczynski: commit log]

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: net: deje que net.core.dev_weight siempre sea distinto de cero. Se encontró el siguiente problema durante la prueba de estabilidad: (NULL net_device): la función de sondeo NAPI process_backlog+0x0/0x530 \ devolvió 1, excediendo su presupuesto de 0. ------------[ cortar aquí ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Dado que el bit NAPI_STATE_SCHED se ha borrado, napi_schedule_rps() se puede volver a activar en enqueue_to_backlog(), lo que causa este problema. Hacer que el peso de napi siempre sea distinto de cero resuelve este problema. Para desencadenar este problema se requiere un administrador de todo el sistema (la configuración no tiene espacio de nombres).

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