Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: liberar ruta antes de inicializar el árbol de extensiones en btrfs_read_locked_inode() En btrfs_read_locked_inode() estamos llamando a btrfs_init_file_extent_tree() mientras mantenemos una ruta con una hoja bloqueada para lectura de un árbol de subvolumen, y btrfs_init_file_extent_tree() puede realizar una asignación GFP_KERNEL, lo que puede activar la recuperación. Esto puede crear una dependencia de bloqueo circular sobre la cual lockdep advierte con el siguiente splat: [6.1433] [6.1574] WARNING: posible dependencia de bloqueo circular detectada [6.1583] 6.18.0+ #4 Tainted: G U [6.1591] [6.1599] kswapd0/117 está intentando adquirir el bloqueo: [6.1606] ffff8d9b6333c5b8 (&delayed_node->mutex){+.+.}-{3:3}, en: __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1625] pero la tarea ya está manteniendo el bloqueo: [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, en: balance_pgdat+0x195/0xc60 [6.1646] cuyo bloqueo ya depende del nuevo bloqueo. [6.1657] la cadena de dependencia existente (en orden inverso) es: [6.1667] -> #2 (fs_reclaim){+.+.}-{0:0}: [6.1677] fs_reclaim_acquire+0x9d/0xd0 [6.1685] __kmalloc_cache_noprof+0x59/0x750 [6.1694] btrfs_init_file_extent_tree+0x90/0x100 [6.1702] btrfs_read_locked_inode+0xc3/0x6b0 [6.1710] btrfs_iget+0xbb/0xf0 [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0 [6.1724] btrfs_lookup+0x12/0x30 [6.1731] lookup_open.isra.0+0x1aa/0x6a0 [6.1739] path_openat+0x5f7/0xc60 [6.1746] do_filp_open+0xd6/0x180 [6.1753] do_sys_openat2+0x8b/0xe0 [6.1760] __x64_sys_openat+0x54/0xa0 [6.1768] do_syscall_64+0x97/0x3e0 [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e [6.1784] -> #1 (btrfs-tree-00){++++}-{3:3}: [6.1794] lock_release+0x127/0x2a0 [6.1801] up_read+0x1b/0x30 [6.1808] btrfs_search_slot+0x8e0/0xff0 [6.1817] btrfs_lookup_inode+0x52/0xd0 [6.1825] __btrfs_update_delayed_inode+0x73/0x520 [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120 [6.1842] btrfs_log_inode+0x608/0x1aa0 [6.1849] btrfs_log_inode_parent+0x249/0xf80 [6.1857] btrfs_log_dentry_safe+0x3e/0x60 [6.1865] btrfs_sync_file+0x431/0x690 [6.1872] do_fsync+0x39/0x80 [6.1879] __x64_sys_fsync+0x13/0x20 [6.1887] do_syscall_64+0x97/0x3e0 [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e [6.1903] -> #0 (&delayed_node->mutex){+.+.}-{3:3}: [6.1913] __lock_acquire+0x15e9/0x2820 [6.1920] lock_acquire+0xc9/0x2d0 [6.1927] __mutex_lock+0xcc/0x10a0 [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0 [6.1944] btrfs_evict_inode+0x20b/0x4b0 [6.1952] evict+0x15a/0x2f0 [6.1958] prune_icache_sb+0x91/0xd0 [6.1966] super_cache_scan+0x150/0x1d0 [6.1974] do_shrink_slab+0x155/0x6f0 [6.1981] shrink_slab+0x48e/0x890 [6.1988] shrink_one+0x11a/0x1f0 [6.1995] shrink_node+0xbfd/0x1320 [6.1002] balance_pgdat+0x67f/0xc60 [6.1321] kswapd+0x1dc/0x3e0 [6.1643] kthread+0xff/0x240 [6.1965] ret_from_fork+0x223/0x280 [6.1287] ret_from_fork_asm+0x1a/0x30 [6.1616] otra información que podría ayudarnos a depurar esto: [6.1561] La cadena existe de: &delayed_node->mutex --> btrfs-tree-00 --> fs_reclaim [6.1503] Posible escenario de bloqueo inseguro: [6.1110] CPU0 CPU1 [6.1411] [6.1707] lock(fs_reclaim); [6.1998] lock(btrfs-tree-00); [6.1291] lock(fs_reclaim); [6.1581] lock(&del ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: corrige el manejo de errores en la init_task durante la carga<br /> <br /> Si la init_task falla durante la carga de un controlador, terminamos sin vports y netdevs, lo que provoca el fallo de todo el proceso. En ese estado, un reinicio posterior resultará en un fallo ya que la tarea de servicio intenta acceder a recursos no inicializados. La siguiente traza es de un error en la init_task donde el CREATE_VPORT (op 501) es rechazado por el FW:<br /> <br /> [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated<br /> [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)<br /> [40958.148190] idpf 0000:83:00.0: HW reset detected<br /> [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> ...<br /> [40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]<br /> [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]<br /> ...<br /> [40958.177932] Call Trace:<br /> [40958.178491] <br /> [40958.179040] process_one_work+0x226/0x6d0<br /> [40958.179609] worker_thread+0x19e/0x340<br /> [40958.180158] ? __pfx_worker_thread+0x10/0x10<br /> [40958.180702] kthread+0x10f/0x250<br /> [40958.181238] ? __pfx_kthread+0x10/0x10<br /> [40958.181774] ret_from_fork+0x251/0x2b0<br /> [40958.182307] ? __pfx_kthread+0x10/0x10<br /> [40958.182834] ret_from_fork_asm+0x1a/0x30<br /> [40958.183370] <br /> <br /> Corrige el manejo de errores en la init_task para asegurar que las tareas de servicio y de buzón estén deshabilitadas si el error ocurre durante la carga. Estas se inician en idpf_vc_core_init(), que genera la init_task y no tiene forma de saber si falló. Si el error ocurre en el reinicio, después de una carga exitosa del controlador, las tareas aún pueden ejecutarse, ya que eso permitirá a los netdevs intentar la recuperación a través de otro reinicio. Detén las devoluciones de llamada de PTP de cualquier manera, ya que estas se reiniciarán con la llamada a idpf_vc_core_init() durante un reinicio exitoso.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> inet: frags: eliminar referencias de conntrack de fraglist<br /> <br /> Jakub añadió una advertencia en nf_conntrack_cleanup_net_list() para hacer más obvia la depuración de skbs/referencias de conntrack filtradas.<br /> <br /> syzbot informa que esto se activa, y también puedo reproducirlo a través de la autoprueba ip_defrag.sh:<br /> <br /> limpieza de conntrack bloqueada durante 60s<br /> ADVERTENCIA: net/netfilter/nf_conntrack_core.c:2512<br /> [..]<br /> <br /> Las limpiezas de conntrack se atascan porque hay skbs que aún mantienen referencias nf_conn a través de su frag_list.<br /> <br /> net.core.skb_defer_max=0 hace que el cuelgue desaparezca.<br /> <br /> Eric Dumazet señala que skb_release_head_state() no sigue la fraglist.<br /> <br /> ip_defrag.sh solo puede reproducir este problema desde el commit 6471658dc66c (&amp;#39;udp: use skb_attempt_defer_free()&amp;#39;), pero AFAICS este problema también podría ocurrir con TCP si el descubrimiento de pmtu está desactivado.<br /> <br /> La ruta del problema relevante para udp es:<br /> 1. netns emite paquetes fragmentados<br /> 2. nf_defrag_v6_hook los reensambla (en el hook de salida)<br /> 3. el skb reensamblado es rastreado (skb posee la referencia nf_conn)<br /> 4. ip6_output refragmenta<br /> 5. los paquetes refragmentados también poseen la referencia nf_conn (ip6_fragment llama a ip6_copy_metadata())<br /> 6. en la ruta de entrada, nf_defrag_v6_hook omite la desfragmentación: los fragmentos ya tienen skb-&amp;gt;nf_conn adjunto<br /> 7. los skbs son reensamblados a través de ipv6_frag_rcv()<br /> 8. skb_consume_udp -&amp;gt; skb_attempt_defer_free() -&amp;gt; skb termina en la freelist de pcpu, pero aún tiene la referencia nf_conn.<br /> <br /> Posibles soluciones:<br /> 1 dejar que el motor de desfragmentación elimine la entrada nf_conn, O<br /> 2 exportar kick_defer_list_purge() y llamarlo desde la devolución de llamada de salida de netns de conntrack, O<br /> 3 añadir una comprobación skb_has_frag_list() a skb_attempt_defer_free()<br /> <br /> 2 y 3 también resuelven el cuelgue de ip_defrag.sh pero comparten el mismo inconveniente:<br /> <br /> Tales skbs reensamblados, encolados al socket, pueden impedir la eliminación del módulo conntrack hasta que el espacio de usuario haya consumido el paquete. Si bien tanto la pila tcp como udp llaman a nf_reset_ct() antes de colocar el skb en la cola del socket, esa función no itera los skbs de frag_list.<br /> <br /> Por lo tanto, eliminar las entradas nf_conn cuando se colocan en la cola de desfragmentación.<br /> Mantener la entrada nf_conn del primer skb (offset 0) para que el skb reensamblado retenga la entrada nf_conn para la ruta TX.<br /> <br /> Tenga en cuenta que la etiqueta de correcciones es incorrecta; apunta al commit que introdujo el &amp;#39;problema reproducible de ip_defrag.sh&amp;#39;: no es necesario hacer un backport de este parche a cada kernel estable.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gpio: mpsse: corregir fuga de referencia en las rutas de error de gpio_mpsse_probe()<br /> <br /> La referencia obtenida al llamar a usb_get_dev() no se libera en las rutas de error de gpio_mpsse_probe(). Corregir eso utilizando funciones auxiliares gestionadas por el dispositivo. También eliminar la llamada a usb_put_dev() en la función de desconexión ya que ahora se liberará automáticamente.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: at_hdmac: corregir fuga de dispositivo en of_dma_xlate()<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo de plataforma DMA durante of_dma_xlate() al liberar los recursos del canal.<br /> <br /> Tenga en cuenta que el commit 3832b78b3ec2 (&amp;#39;dmaengine: at_hdmac: añadir llamada put_device() faltante en at_dma_xlate()&amp;#39;) corrigió la fuga en un par de rutas de error, pero la referencia aún se está fugando en una asignación exitosa.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: bcm-sba-raid: corregir fuga de dispositivo en la sonda<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo de buzón durante la sonda en fallos de la sonda y al desvincular el controlador.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: dw: dmamux: corregir fuga de nodo OF en fallo de asignación de ruta<br /> <br /> Asegúrese de liberar la referencia tomada al nodo OF maestro de DMA también en fallos tardíos de asignación de ruta.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: lpc18xx-dmamux: corregir fuga de dispositivo en la asignación de ruta<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo de plataforma DMA mux durante la asignación de ruta.<br /> <br /> Tenga en cuenta que mantener una referencia a un dispositivo no evita que los datos de su controlador desaparezcan, por lo que no tiene sentido mantener la referencia.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: sh: rz-dmac: corregir fuga de dispositivo en fallo de sondeo<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo ICU durante el sondeo también en fallos de sondeo (p. ej., aplazamiento del sondeo).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: stm32: dmamux: corregir fuga de dispositivo en la asignación de ruta<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo de plataforma DMA mux durante la asignación de ruta.<br /> <br /> Tenga en cuenta que mantener una referencia a un dispositivo no evita que los datos de su controlador desaparezcan, por lo que no tiene sentido mantener la referencia.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: ti: dma-crossbar: corregir fuga de dispositivo en la asignación de ruta am335x<br /> <br /> Asegúrese de liberar la referencia tomada al buscar el dispositivo de plataforma crossbar durante la asignación de ruta am335x.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> btrfs: corrección de desreferencia de NULL en la raíz al rastrear el desalojo de inodos<br /> <br /> Al desalojar un inodo, lo primero que hacemos es configurar el rastreo para él, lo que implica obtener el ID de la raíz. Pero en btrfs_evict_inode(), la raíz podría ser NULL, como se implica en la siguiente comprobación que hacemos en btrfs_evict_inode().<br /> <br /> Por lo tanto, deberíamos establecer el -&amp;gt;root_objectid a 0 en caso de que la raíz sea NULL, o movemos la configuración del rastreo después de comprobar que la raíz no es NULL. Establecer el rootid a 0 al menos nos da la posibilidad de rastrear esta llamada incluso en el caso de que la raíz sea NULL, así que esa es la solución adoptada aquí.