Vulnerabilidades

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

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.

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: ax25: rcu protect dev->ax25_ptr syzbot encontró un problema de lockdep [1]. Deberíamos eliminar la dependencia RTNL de ax25 en ax25_setsockopt(). Esto también debería solucionar una variedad de posibles UAF en ax25. [1] ADVERTENCIA: se detectó una posible dependencia de bloqueo circular 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: protege el acceso a los búferes sin referencias activas nilfs_lookup_dirty_data_búferes(), que itera a través de los búferes adjuntos a los folios/páginas de datos sucios, accede a los búferes adjuntos sin bloquear los folios/páginas. Para el caché de datos, nilfs_clear_folio_dirty() puede llamarse de forma asincrónica cuando el sistema de archivos se degenera a solo lectura, por lo que nilfs_lookup_dirty_data_búferes() aún tiene el potencial de causar problemas de use after free cuando los búferes pierden la protección de su estado sucio a mitad de camino debido a esta limpieza asincrónica y son liberados involuntariamente por try_to_free_búferes(). Elimine este problema de ejecución ajustando la sección de bloqueo en esta función.

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: 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: ptp: Asegúrese de que la devolución de llamada info->enable esté siempre establecida Los controladores ioctl y sysfs llaman incondicionalmente a la devolución de llamada ->enable. No todos los controladores implementan esa devolución de llamada, lo que lleva a desreferencias NULL. Ejemplo de controladores afectados: ptp_s390.c, ptp_vclock.c y ptp_mock.c. En su lugar, utilice una devolución de llamada ficticia si el controlador no especificó nada mejor.

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

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().