Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/huc: corrección de la valla no liberada en errores de sondeo tempranos La valla de carga retrasada de HuC, introducida con la confirmación 27536e03271da ("drm/i915/huc: rastrear la carga retrasada de HuC con una valla"), se registra con el rastreador de objetos en las primeras etapas del sondeo del controlador, pero se desregistra solo desde la eliminación del controlador, que no se llama en errores de sondeo tempranos. Dado que su memoria se asigna en devres y luego se libera de todos modos, puede suceder que se asigne nuevamente a la valla y se reutilice en futuras sondas del controlador, lo que genera advertencias del kernel que contaminan el kernel: <4> [309.731371] ------------[ cortar aquí ]------------ <3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915] <4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0 ... <4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G U 6.14.0-CI_DRM_16362-gf0fd77956987+ #1 ... <4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0 ... <4> [309.731728] Call Trace: <4> [309.731730] ... <4> [309.731949] __debug_object_init+0x17b/0x1c0 <4> [309.731957] debug_object_init+0x34/0x50 <4> [309.732126] __i915_sw_fence_init+0x34/0x60 [i915] <4> [309.732256] intel_huc_init_early+0x4b/0x1d0 [i915] <4> [309.732468] intel_uc_init_early+0x61/0x680 [i915] <4> [309.732667] intel_gt_common_init_early+0x105/0x130 [i915] <4> [309.732804] intel_root_gt_init_early+0x63/0x80 [i915] <4> [309.732938] i915_driver_probe+0x1fa/0xeb0 [i915] <4> [309.733075] i915_pci_probe+0xe6/0x220 [i915] <4> [309.733198] local_pci_probe+0x44/0xb0 <4> [309.733203] pci_device_probe+0xf4/0x270 <4> [309.733209] really_probe+0xee/0x3c0 <4> [309.733215] __driver_probe_device+0x8c/0x180 <4> [309.733219] driver_probe_device+0x24/0xd0 <4> [309.733223] __driver_attach+0x10f/0x220 <4> [309.733230] bus_for_each_dev+0x7d/0xe0 <4> [309.733236] driver_attach+0x1e/0x30 <4> [309.733239] bus_add_driver+0x151/0x290 <4> [309.733244] driver_register+0x5e/0x130 <4> [309.733247] __pci_register_driver+0x7d/0x90 <4> [309.733251] i915_pci_register_driver+0x23/0x30 [i915] <4> [309.733413] i915_init+0x34/0x120 [i915] <4> [309.733655] do_one_initcall+0x62/0x3f0 <4> [309.733667] do_init_module+0x97/0x2a0 <4> [309.733671] load_module+0x25ff/0x2890 <4> [309.733688] init_module_from_file+0x97/0xe0 <4> [309.733701] idempotent_init_module+0x118/0x330 <4> [309.733711] __x64_sys_finit_module+0x77/0x100 <4> [309.733715] x64_sys_call+0x1f37/0x2650 <4> [309.733719] do_syscall_64+0x91/0x180 <4> [309.733763] entry_SYSCALL_64_after_hwframe+0x76/0x7e <4> [309.733792] ... <4> [309.733806] ---[ fin de seguimiento 000000000000000 ]--- Este escenario se reproduce con mayor facilidad con igt@i915_module_load@reload-with-fault-injection. Solucione el problema trasladando el paso de limpieza a la ruta de la versión del controlador. (Seleccionado de la confirmación 795dbde92fe5c6996a02a5b579481de73035e7bf)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: libwx: error en el controlador page_pool_dev_alloc_pages. page_pool_dev_alloc_pages podría devolver NULL. Se ejecutó un WARN_ON(!page), pero seguía usando el puntero NULL y se bloqueaba. Esto es similar a la confirmación 001ba0902046 ("net: fec: error en el controlador page_pool_dev_alloc_pages"). Esta vulnerabilidad fue detectada por nuestra herramienta de análisis estático Knighter.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: explícitamente deshabilitar la desconexión. syzbot descubrió que puede desconectar un socket TLS y luego encontrarse con todo tipo de casos inesperados. Recuerdo vagamente que Eric nos lo señaló hace mucho tiempo. Admitir la desconexión es muy difícil; por ejemplo, si la descarga está habilitada, tendríamos que esperar a que se ackearan todos los paquetes. La desconexión no se usa comúnmente; deshabilitarla. El problema inmediato con el que se encuentra syzbot es la advertencia en el strp, pero ese es simplemente el error más fácil de activar: ADVERTENCIA: CPU: 0 PID: 5834 en net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Rastreo de llamada: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [en línea] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: se corrige una fuga de memoria en tipc_link_xmit. Si la cola de transmisión de mensajes importantes del sistema está sobrecargada, tipc_link_xmit() devuelve -ENOBUFS, pero la lista de skb no se purga. Esto provoca una fuga de memoria y un fallo al asignar un skb. Esta confirmación corrige este problema purgando la lista de skb antes del retorno de tipc_link_xmit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: pata_pxa: Se corrige la posible desreferencia de punteros nulos en pxa_ata_probe(). Devm_ioremap() devuelve NULL en caso de error. Actualmente, pxa_ata_probe() no verifica este caso, lo que puede provocar una desreferencia de punteros nulos. Agregue la comprobación de NULL después de devm_ioremap() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ublk: corrección del manejo de la recuperación y la reemisión en ublk_abort_queue(). La confirmación 8284066946e6 ("ublk: toma la referencia de la solicitud cuando la solicitud es manejada por el espacio de usuario") no toma la referencia de la solicitud en caso de reemisión de recuperación. En ese caso, la solicitud se puede volver a poner en cola y reenviar, y falla al cancelar el comando "uring". Si es una solicitud zc, la solicitud se puede liberar antes de que io_uring devuelva el buffer zc, y luego cause pánico en el kernel: [ 126.773061] ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000c8 [ 126.773657] #PF: acceso de lectura del supervisor en modo kernel [ 126.774052] #PF: error_code(0x0000) - página no presente [ 126.774455] PGD 0 P4D 0 [ 126.774698] Oops: Oops: 0000 [#1] SMP NOPTI [ 126.775034] CPU: 13 UID: 0 PID: 1612 Comm: kworker/u64:55 No contaminado 6.14.0_blk+ #182 PREEMPT(full) [ 126.775676] Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 01/04/2014 [ 126.776275] Cola de trabajo: iou_exit io_ring_exit_work [ 126.776651] RIP: 0010:ublk_io_release+0x14/0x130 [ublk_drv] Lo corrige tomando siempre la referencia de la solicitud para abortar la solicitud.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar fugas de memoria al habilitar las estadísticas. El controlador utiliza anillos de destino del monitor para el modo de estadísticas extendidas y el modo de monitor independiente. En el modo de estadísticas extendidas, los TLV se analizan desde el búfer recibido del anillo de destino del monitor y se asignan a la estructura ppdu_info para actualizar las estadísticas por paquete. En el modo de monitor independiente, junto con las estadísticas por paquete, se capturan los datos del paquete (carga útil) y el controlador actualiza por MSDU a mac80211. Cuando la interfaz AP está habilitada, solo se activa el modo de estadísticas extendidas. Como parte de la habilitación de los anillos de monitor para recopilar estadísticas, el controlador se suscribe al TLV HAL_RX_MPDU_START en la configuración del filtro. Este TLV se recibe del anillo de destino del monitor y se produce kzalloc para el objeto mon_mpdu, que no se libera, lo que provoca una fuga de memoria. El kzalloc para el objeto mon_mpdu solo es necesario mientras se habilita la interfaz de monitor independiente. Esto causa una fuga de memoria al habilitar el modo de estadísticas extendidas en el controlador. Solucione esta fuga de memoria eliminando el kzalloc del objeto mon_mpdu en la gestión de la TLV HAL_RX_MPDU_START. Además, elimine la gestión del modo de monitor independiente en las TLV HAL_MON_BUF_ADDR y HAL_RX_MSDU_END. Estas etiquetas TLV se gestionarán correctamente al habilitar el modo de monitor independiente en el futuro. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: se corrige la pérdida de memoria en ath12k_pci_remove() Kmemleak informó este error: objeto sin referencia 0xffff1c165cec3060 (tamaño 32): comm "insmod", pid 560, jiffies 4296964570 (edad 235.596s) backtrace: [<000000005434db68>] __kmem_cache_alloc_node+0x1f4/0x2c0 [<000000001203b155>] kmalloc_trace+0x40/0x88 [<0000000028adc9c8>] _request_firmware+0xb8/0x608 [<00000000cad1aef7>] firmware_request_nowarn+0x50/0x80 [<000000005011a682>] local_pci_probe+0x48/0xd0 [<00000000077cd295>] pci_device_probe+0xb4/0x200 [<0000000087184c94>] really_probe+0x150/0x2c0 La memoria del firmware se asignó en ath12k_pci_probe(), pero no se liberó en ath12k_pci_remove() si el bit ATH12K_FLAG_QMI_FAIL está activado. Por lo tanto, se llama ath12k_fw_unmap() para liberar la memoria. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.2.0-02280-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernate: Evitar interbloqueo en hibernate_compressor_param_set(). syzbot reportó un interbloqueo en lock_system_sleep() (ver más abajo). La operación de escritura en "/sys/module/hibernate/parameters/compressor" entra en conflicto con el registro del dispositivo ieee80211, lo que resulta en un interbloqueo al intentar adquirir system_transition_mutex bajo param_lock. Para evitar este interbloqueo, modifique hibernate_compressor_param_set() para usar mutex_trylock() al intentar adquirir system_transition_mutex y devolver -EBUSY si falla. No es necesario guardar ni ajustar los indicadores de tarea antes de llamar a mutex_trylock(&system_transition_mutex), ya que el llamador no esperará este mutex y, si se ejecuta simultáneamente con la suspensión del sistema en curso, se congelará correctamente al regresar al espacio de usuario. Informe de syzbot: syz-executor895/5833 está intentando adquirir el bloqueo: ffffffff8e0828c8 (system_transition_mutex){+.+.}-{4:4}, en: lock_system_sleep+0x87/0xa0 kernel/power/main.c:56 pero la tarea ya tiene el bloqueo: ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: kernel_param_lock kernel/params.c:607 [en línea] ffffffff8e07dc68 (param_lock){+.+.}-{4:4}, en: param_attr_store+0xe6/0x300 kernel/params.c:586 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #3 (param_lock){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 ieee80211_rate_control_ops_get net/mac80211/rate.c:220 [en línea] rate_control_alloc net/mac80211/rate.c:266 [en línea] ieee80211_init_rate_ctrl_alg+0x18d/0x6b0 net/mac80211/rate.c:1015 ieee80211_register_hw+0x20cd/0x4060 net/mac80211/main.c:1531 mac80211_hwsim_new_radio+0x304e/0x54e0 drivers/net/wireless/virtual/mac80211_hwsim.c:5558 init_mac80211_hwsim+0x432/0x8c0 drivers/net/wireless/virtual/mac80211_hwsim.c:6910 hacer_una_initcall+0x128/0x700 init/main.c:1257 hacer_nivel_initcall init/main.c:1319 [en línea] hacer_initcalls init/main.c:1335 [en línea] hacer_configuración_básica init/main.c:1354 [en línea] kernel_init_freeable+0x5c7/0x900 init/main.c:1568 kernel_init+0x1c/0x2b0 init/main.c:1457 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 -> #2 (rtnl_mutex){+.+.}-{4:4}: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0x19b/0xb10 kernel/locking/mutex.c:730 wg_pm_notification drivers/net/wireguard/device.c:80 [en línea] wg_pm_notification+0x49/0x180 controladores/net/wireguard/device.c:64 cadena_de_llamadas_del_notificador+0xb7/0x410 kernel/notifier.c:85 cadena_de_llamadas_del_notificador_robust kernel/notifier.c:120 [en línea] cadena_de_llamadas_del_notificador_robust kernel/notifier.c:345 [en línea] cadena_de_llamadas_del_notificador_robust+0xc9/0x170 kernel/notifier.c:333 cadena_de_llamadas_del_notificador_robust+0x27/0x60 kernel/power/main.c:102 snapshot_open+0x189/0x2b0 kernel/power/user.c:77 misc_open+0x35a/0x420 controladores/char/misc.c:179 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x735/0x1c40 fs/open.c:956 vfs_open+0x82/0x3f0 fs/open.c:1086 do_open fs/namei.c:3830 [en línea] path_openat+0x1e88/0x2d80 fs/namei.c:3989 do_filp_open+0x20c/0x470 fs/namei.c:4016 do_sys_openat2+0x17a/0x1e0 fs/open.c:1428 do_sys_open fs/open.c:1443 [en línea] __do_sys_openat fs/open.c:1459 [en línea] __se_sys_openat fs/open.c:1454 [en línea] __x64_sys_openat+0x175/0x210 fs/open.c:1454 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 ((pm_chain_head).rwsem){++++}-{4:4}: down_read+0x9a/0x330 kernel/locking/rwsem.c:1524 blocking_notifier_call_chain_robust kernel ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/dwc_pcie: se corrigen dispositivos pci_dev duplicados. Durante platform_device_register, el uso incorrecto de struct device pci_dev como platform_data provocaba una copia kmemdup de pci_dev. Peor aún, acceder al dispositivo duplicado provoca la corrupción de la lista, ya que su contenido mutex (p. ej., list, magic) permanece igual que el original.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Se soluciona el bloqueo al liberar el evento sigtrap Perf puede bloquearse al liberar un evento sigtrap si no se ha logrado enviar una señal diferida relacionada antes de que se cerrara el archivo: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Una vez que task_work_run() se está ejecutando, la lista de devoluciones de llamadas pendientes se elimina de task_struct y desde este punto, task_work_cancel() no puede eliminar ningún elemento de trabajo pendiente y aún no iniciado, de ahí el error de task_work_cancel() y el bloqueo de rcuwait_wait_event(). El trabajo de la tarea se puede cambiar para eliminar un trabajo a la vez, de modo que un trabajo que se ejecuta en la tarea actual siempre puede cancelar uno pendiente, sin embargo, el diseño de espera/activación aún está sujeto a dependencias invertidas cuando se involucran objetivos remotos, como lo ilustra Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Por lo tanto, la única opción que queda es adquirir el recuento de referencias de evento al poner en cola el trabajo de la tarea de rendimiento y liberarlo del trabajo de la tarea. Tal como se hizo antes de 3a5465418f5f ("perf: Corregir fuga de eventos al ejecutar y liberar archivos"), pero sin las fugas corregidas. Se requieren algunos ajustes para que funcione: * Un evento secundario podría desreferenciar a su padre al liberarse. Se debe tener cuidado de liberar al padre al final. * Algunos sitios, al asumir que el evento no tiene ninguna referencia retenida y, por lo tanto, puede liberarse de inmediato, deben colocar la referencia y dejar que el recuento de referencias continúe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/mediatek: Se ha corregido la deferencia de puntero nulo en mtk_iommu_device_group. Actualmente, mtk_iommu invoca durante el sondeo de iommu_device_register antes de que se inicialice hw_list de los datos del controlador. Desde la corrección del problema de sondeo de iommu, este provoca la desreferencia de puntero nulo en mtk_iommu_device_group cuando se accede a hw_list con list_first_entry (no es seguro para nulos). Por lo tanto, se debe modificar el orden de las llamadas para garantizar que iommu_device_register se invoque después de inicializar los datos del controlador.