Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: liberar la ruta antes de iget_failed() en btrfs_read_locked_inode() En btrfs_read_locked_inode() si no logramos buscar el inodo, saltamos a la etiqueta 'out' con una ruta que tiene una hoja bloqueada para lectura y luego llamamos a iget_failed(). Esto puede resultar en un interbloqueo ABBA, ya que iget_failed() activa el desalojo del inodo y eso causa la liberación del inodo retrasado, el cual debe bloquear el mutex del inodo retrasado, y una tarea que actualiza un inodo retrasado comienza tomando el mutex del nodo y luego modificando el btree del subvolumen del inodo. Syzbot informó el siguiente splat de lockdep para esto: ADVERTENCIA: posible dependencia de bloqueo circular detectada syzkaller #0 No contaminado btrfs-cleaner/8725 está intentando adquirir el bloqueo: ffff0000d6826a48 (&delayed_node->mutex){+.+.}-{4:4}, en: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290 pero la tarea ya tiene el bloqueo: ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, en: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (btrfs-tree-00){++++}-{4:4}: __lock_release kernel/locking/lockdep.c:5574 [en línea] lock_release+0x198/0x39c kernel/locking/lockdep.c:5889 up_read+0x24/0x3c kernel/locking/rwsem.c:1632 btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169 btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [en línea] btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133 btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395 __btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [en línea] __btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141 __btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176 btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219 flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828 do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158 btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226 process_one_work+0x7e8/0x155c kernel/workqueue.c:3263 process_scheduled_works kernel/workqueue.c:3346 [en línea] worker_thread+0x958/0xed8 kernel/workqueue.c:3427 kthread+0x5fc/0x75c kernel/kthread.c:463 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844 -> #0 (&delayed_node->mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3165 [en línea] check_prevs_add kernel/locking/lockdep.c:3284 [en línea] validate_chain kernel/locking/lockdep.c:3908 [en línea] __lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237 lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868 __mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598 __mutex_lock kernel/locking/mutex.c:760 [en línea] mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812 __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [en línea] btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326 btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587 evict+0x414/0x928 fs/inode.c:810 iput_final fs/inode.c:1914 [en línea] iput+0x95c/0xad4 fs/inode.c:1966 iget_failed+0xec/0x134 fs/bad_inode.c:248 btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101 btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837 trfs_run_defrag_inode fs/btrfs/defrag.c:237 [en línea] btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: corrige fuga de memoria en idpf_vc_core_deinit()<br /> <br /> Asegúrate de liberar hw-&amp;gt;lan_regs. Reportado por kmemleak durante el reinicio:<br /> <br /> objeto sin referencia 0xff1b913d02a936c0 (tamaño 96):<br /> comm kworker/u258:14, pid 2174, jiffies 4294958305<br /> volcado hexadecimal (primeros 32 bytes):<br /> 00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00 ......-.........<br /> 00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff ..@.......%...-.<br /> rastreo (crc 36063c4f):<br /> __kmalloc_noprof+0x48f/0x890<br /> idpf_vc_core_init+0x6ce/0x9b0 [idpf]<br /> idpf_vc_event_task+0x1fb/0x350 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30

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: 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 (&amp;amp;delayed_node-&amp;gt;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] -&amp;gt; #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] -&amp;gt; #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] -&amp;gt; #0 (&amp;amp;delayed_node-&amp;gt;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: &amp;amp;delayed_node-&amp;gt;mutex --&amp;gt; btrfs-tree-00 --&amp;gt; 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(&amp;amp;del ---truncado---

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: marvell: prestera: corregir desreferencia NULL en caso de fallo de devlink_alloc()<br /> <br /> devlink_alloc() puede devolver NULL en caso de fallo de asignación, pero prestera_devlink_alloc() llama incondicionalmente a devlink_priv() sobre el puntero devuelto.<br /> <br /> Esto conduce a una desreferencia de puntero NULL si la asignación de devlink falla.<br /> Añadir una comprobación para un puntero devlink NULL y devolver NULL anticipadamente para evitar el fallo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: 3com: 3c59x: corrección de posible desreferencia nula en vortex_probe1()<br /> <br /> pdev puede ser nulo y free_ring: puede ser llamado en 1297 con un pdev nulo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: usb: pegasus: corregir fuga de memoria en update_eth_regs_async()<br /> <br /> Cuando se escribe asincrónicamente en los registros del dispositivo y si usb_submit_urb() falla, el código falla en liberar los recursos asignados hasta este punto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: corrección de fuga de memoria en idpf_vport_rel()<br /> <br /> Libera vport-&amp;gt;rx_ptype_lkup en idpf_vport_rel() para evitar la fuga de memoria durante un reinicio. Reportado por kmemleak:<br /> <br /> objeto sin referencia 0xff450acac838a000 (tamaño 4096):<br /> comm &amp;#39;kworker/u258:5&amp;#39;, pid 7732, jiffies 4296830044<br /> volcado hexadecimal (primeros 32 bytes):<br /> 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................<br /> rastreo (crc 3da81902):<br /> __kmalloc_cache_noprof+0x469/0x7a0<br /> idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]<br /> idpf_init_task+0x1ec/0x8d0 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> idpf: corrige una fuga de memoria de la lista de dirección de flujo al desinstalar el módulo<br /> <br /> La lista de dirección de flujo mantiene entradas que se añaden y eliminan a medida que ethtool crea y elimina reglas de dirección de flujo. La eliminación del módulo con entradas activas provoca una fuga de memoria ya que la lista no se limpia correctamente.<br /> <br /> Esto se evita iterando a través de las entradas restantes en la lista y liberando la memoria asociada durante la eliminación del módulo. Se añade un spinlock (flow_steer_list_lock) para proteger el acceso a la lista de múltiples hilos.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> mm/page_alloc: evitar la corrupción de pcp con SMP=n<br /> <br /> El robot de pruebas del kernel ha informado:<br /> <br /> BUG: spinlock trylock failure on UP on CPU#0, kcompactd0/28<br /> lock: 0xffff888807e35ef0, .magic: dead4ead, .owner: kcompactd0/28, .owner_cpu: 0<br /> CPU: 0 UID: 0 PID: 28 Comm: kcompactd0 Not tainted 6.18.0-rc5-00127-ga06157804399 #1 PREEMPT 8cc09ef94dcec767faa911515ce9e609c45db470<br /> Call Trace:<br /> <br /> __dump_stack (lib/dump_stack.c:95)<br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> dump_stack (lib/dump_stack.c:130)<br /> spin_dump (kernel/locking/spinlock_debug.c:71)<br /> do_raw_spin_trylock (kernel/locking/spinlock_debug.c:?)<br /> _raw_spin_trylock (include/linux/spinlock_api_smp.h:89 kernel/locking/spinlock.c:138)<br /> __free_frozen_pages (mm/page_alloc.c:2973)<br /> ___free_pages (mm/page_alloc.c:5295)<br /> __free_pages (mm/page_alloc.c:5334)<br /> tlb_remove_table_rcu (include/linux/mm.h:? include/linux/mm.h:3122 include/asm-generic/tlb.h:220 mm/mmu_gather.c:227 mm/mmu_gather.c:290)<br /> ? __cfi_tlb_remove_table_rcu (mm/mmu_gather.c:289)<br /> ? rcu_core (kernel/rcu/tree.c:?)<br /> rcu_core (include/linux/rcupdate.h:341 kernel/rcu/tree.c:2607 kernel/rcu/tree.c:2861)<br /> rcu_core_si (kernel/rcu/tree.c:2879)<br /> handle_softirqs (arch/x86/include/asm/jump_label.h:36 include/trace/events/irq.h:142 kernel/softirq.c:623)<br /> __irq_exit_rcu (arch/x86/include/asm/jump_label.h:36 kernel/softirq.c:725)<br /> irq_exit_rcu (kernel/softirq.c:741)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1052)<br /> <br /> <br /> RIP: 0010:_raw_spin_unlock_irqrestore (arch/x86/include/asm/preempt.h:95 include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:194)<br /> free_pcppages_bulk (mm/page_alloc.c:1494)<br /> drain_pages_zone (include/linux/spinlock.h:391 mm/page_alloc.c:2632)<br /> __drain_all_pages (mm/page_alloc.c:2731)<br /> drain_all_pages (mm/page_alloc.c:2747)<br /> kcompactd (mm/compaction.c:3115)<br /> kthread (kernel/kthread.c:465)<br /> ? __cfi_kcompactd (mm/compaction.c:3166)<br /> ? __cfi_kthread (kernel/kthread.c:412)<br /> ret_from_fork (arch/x86/kernel/process.c:164)<br /> ? __cfi_kthread (kernel/kthread.c:412)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:255)<br /> <br /> <br /> Matthew ha analizado el informe y ha identificado que en drain_page_zone() estamos en una sección protegida por spin_lock(&amp;amp;pcp-&amp;gt;lock) y luego recibimos una interrupción que intenta spin_trylock() en el mismo bloqueo. El código está diseñado para funcionar de esta manera sin deshabilitar las IRQ y ocasionalmente fallar el trylock con un mecanismo de respaldo. Sin embargo, la implementación de spinlock con SMP=n asume que spin_trylock() siempre tendrá éxito, y por lo tanto, normalmente es una operación nula. Aquí, la depuración de bloqueo habilitada detecta el problema, pero de lo contrario podría causar una corrupción de la estructura pcp.<br /> <br /> El problema ha sido introducido por el commit 574907741599 (&amp;#39;mm/page_alloc: dejar las IRQ habilitadas para las asignaciones de páginas por CPU&amp;#39;). El esquema de bloqueo de pcp reconoce la necesidad de deshabilitar las IRQ para evitar el anidamiento de secciones spin_trylock() en SMP=n, pero la necesidad de evitar el anidamiento en spin_lock() no ha sido reconocida. Solucionarlo introduciendo envoltorios locales que cambian el spin_lock() a spin_lock_iqsave() con SMP=n y usándolos en todos los lugares que realizan spin_lock(&amp;amp;pcp-&amp;gt;lock).<br /> <br /> [vbabka@suse.cz: añadir el prefijo pcp_ a los envoltorios spin_lock_irqsave, según Steven]

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> dmaengine: qcom: gpi: Corrección de fuga de memoria en gpi_peripheral_config()<br /> <br /> Corrige una fuga de memoria en gpi_peripheral_config() donde la memoria original apuntada por gchan-&amp;gt;config podría perderse si krealloc() falla.<br /> <br /> El problema ocurre cuando:<br /> 1. gchan-&amp;gt;config apunta a memoria previamente asignada<br /> 2. krealloc() falla y devuelve NULL<br /> 3. La función asigna directamente NULL a gchan-&amp;gt;config, perdiendo la referencia a la memoria original<br /> 4. La memoria original se vuelve inalcanzable y no puede ser liberada<br /> <br /> Corrige esto utilizando una variable temporal para contener el resultado de krealloc() y actualizando gchan-&amp;gt;config solo cuando la asignación tiene éxito.<br /> <br /> Encontrado mediante análisis estático y revisión de código.

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.