Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: omap-dma: fix dma_pool resource leak in error paths<br /> <br /> The dma_pool created by dma_pool_create() is not destroyed when<br /> dma_async_device_register() or of_dma_controller_register() fails,<br /> causing a resource leak in the probe error paths.<br /> <br /> Add dma_pool_destroy() in both error paths to properly release the<br /> allocated dma_pool resource.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: pegasus: fix memory leak in update_eth_regs_async()<br /> <br /> When asynchronously writing to the device registers and if usb_submit_urb()<br /> fail, the code fail to release allocated to this point resources.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vc_core_deinit()<br /> <br /> Make sure to free hw-&gt;lan_regs. Reported by kmemleak during reset:<br /> <br /> unreferenced object 0xff1b913d02a936c0 (size 96):<br /> comm "kworker/u258:14", pid 2174, jiffies 4294958305<br /> hex dump (first 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 /> backtrace (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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vport_rel()<br /> <br /> Free vport-&gt;rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory<br /> during a reset. Reported by kmemleak:<br /> <br /> unreferenced object 0xff450acac838a000 (size 4096):<br /> comm "kworker/u258:5", pid 7732, jiffies 4296830044<br /> hex dump (first 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 /> backtrace (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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak of flow steer list on rmmod<br /> <br /> The flow steering list maintains entries that are added and removed as<br /> ethtool creates and deletes flow steering rules. Module removal with active<br /> entries causes memory leak as the list is not properly cleaned up.<br /> <br /> Prevent this by iterating through the remaining entries in the list and<br /> freeing the associated memory during module removal. Add a spinlock<br /> (flow_steer_list_lock) to protect the list access from multiple threads.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_alloc: prevent pcp corruption with SMP=n<br /> <br /> The kernel test robot has reported:<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 has analyzed the report and identified that in drain_page_zone()<br /> we are in a section protected by spin_lock(&amp;pcp-&gt;lock) and then get an<br /> interrupt that attempts spin_trylock() on the same lock. The code is<br /> designed to work this way without disabling IRQs and occasionally fail the<br /> trylock with a fallback. However, the SMP=n spinlock implementation<br /> assumes spin_trylock() will always succeed, and thus it&amp;#39;s normally a<br /> no-op. Here the enabled lock debugging catches the problem, but otherwise<br /> it could cause a corruption of the pcp structure.<br /> <br /> The problem has been introduced by commit 574907741599 ("mm/page_alloc:<br /> leave IRQs enabled for per-cpu page allocations"). The pcp locking scheme<br /> recognizes the need for disabling IRQs to prevent nesting spin_trylock()<br /> sections on SMP=n, but the need to prevent the nesting in spin_lock() has<br /> not been recognized. Fix it by introducing local wrappers that change the<br /> spin_lock() to spin_lock_iqsave() with SMP=n and use them in all places<br /> that do spin_lock(&amp;pcp-&gt;lock).<br /> <br /> [vbabka@suse.cz: add pcp_ prefix to the spin_lock_irqsave wrappers, per Steven]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: gpi: Fix memory leak in gpi_peripheral_config()<br /> <br /> Fix a memory leak in gpi_peripheral_config() where the original memory<br /> pointed to by gchan-&gt;config could be lost if krealloc() fails.<br /> <br /> The issue occurs when:<br /> 1. gchan-&gt;config points to previously allocated memory<br /> 2. krealloc() fails and returns NULL<br /> 3. The function directly assigns NULL to gchan-&gt;config, losing the<br /> reference to the original memory<br /> 4. The original memory becomes unreachable and cannot be freed<br /> <br /> Fix this by using a temporary variable to hold the krealloc() result<br /> and only updating gchan-&gt;config when the allocation succeeds.<br /> <br /> Found via static analysis and code review.

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