Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before initializing extent tree in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()<br /> while holding a path with a read locked leaf from a subvolume tree, and<br /> btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can<br /> trigger reclaim.<br /> <br /> This can create a circular lock dependency which lockdep warns about with<br /> the following splat:<br /> <br /> [6.1433] ======================================================<br /> [6.1574] WARNING: possible circular locking dependency detected<br /> [6.1583] 6.18.0+ #4 Tainted: G U<br /> [6.1591] ------------------------------------------------------<br /> [6.1599] kswapd0/117 is trying to acquire lock:<br /> [6.1606] ffff8d9b6333c5b8 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1625]<br /> but task is already holding lock:<br /> [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60<br /> [6.1646]<br /> which lock already depends on the new lock.<br /> <br /> [6.1657]<br /> the existing dependency chain (in reverse order) is:<br /> [6.1667]<br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> [6.1677] fs_reclaim_acquire+0x9d/0xd0<br /> [6.1685] __kmalloc_cache_noprof+0x59/0x750<br /> [6.1694] btrfs_init_file_extent_tree+0x90/0x100<br /> [6.1702] btrfs_read_locked_inode+0xc3/0x6b0<br /> [6.1710] btrfs_iget+0xbb/0xf0<br /> [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0<br /> [6.1724] btrfs_lookup+0x12/0x30<br /> [6.1731] lookup_open.isra.0+0x1aa/0x6a0<br /> [6.1739] path_openat+0x5f7/0xc60<br /> [6.1746] do_filp_open+0xd6/0x180<br /> [6.1753] do_sys_openat2+0x8b/0xe0<br /> [6.1760] __x64_sys_openat+0x54/0xa0<br /> [6.1768] do_syscall_64+0x97/0x3e0<br /> [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1784]<br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> [6.1794] lock_release+0x127/0x2a0<br /> [6.1801] up_read+0x1b/0x30<br /> [6.1808] btrfs_search_slot+0x8e0/0xff0<br /> [6.1817] btrfs_lookup_inode+0x52/0xd0<br /> [6.1825] __btrfs_update_delayed_inode+0x73/0x520<br /> [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120<br /> [6.1842] btrfs_log_inode+0x608/0x1aa0<br /> [6.1849] btrfs_log_inode_parent+0x249/0xf80<br /> [6.1857] btrfs_log_dentry_safe+0x3e/0x60<br /> [6.1865] btrfs_sync_file+0x431/0x690<br /> [6.1872] do_fsync+0x39/0x80<br /> [6.1879] __x64_sys_fsync+0x13/0x20<br /> [6.1887] do_syscall_64+0x97/0x3e0<br /> [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1903]<br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> [6.1913] __lock_acquire+0x15e9/0x2820<br /> [6.1920] lock_acquire+0xc9/0x2d0<br /> [6.1927] __mutex_lock+0xcc/0x10a0<br /> [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1944] btrfs_evict_inode+0x20b/0x4b0<br /> [6.1952] evict+0x15a/0x2f0<br /> [6.1958] prune_icache_sb+0x91/0xd0<br /> [6.1966] super_cache_scan+0x150/0x1d0<br /> [6.1974] do_shrink_slab+0x155/0x6f0<br /> [6.1981] shrink_slab+0x48e/0x890<br /> [6.1988] shrink_one+0x11a/0x1f0<br /> [6.1995] shrink_node+0xbfd/0x1320<br /> [6.1002] balance_pgdat+0x67f/0xc60<br /> [6.1321] kswapd+0x1dc/0x3e0<br /> [6.1643] kthread+0xff/0x240<br /> [6.1965] ret_from_fork+0x223/0x280<br /> [6.1287] ret_from_fork_asm+0x1a/0x30<br /> [6.1616]<br /> other info that might help us debug this:<br /> <br /> [6.1561] Chain exists of:<br /> &amp;delayed_node-&gt;mutex --&gt; btrfs-tree-00 --&gt; fs_reclaim<br /> <br /> [6.1503] Possible unsafe locking scenario:<br /> <br /> [6.1110] CPU0 CPU1<br /> [6.1411] ---- ----<br /> [6.1707] lock(fs_reclaim);<br /> [6.1998] lock(btrfs-tree-00);<br /> [6.1291] lock(fs_reclaim);<br /> [6.1581] lock(&amp;del<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix NULL dereference on devlink_alloc() failure<br /> <br /> devlink_alloc() may return NULL on allocation failure, but<br /> prestera_devlink_alloc() unconditionally calls devlink_priv() on<br /> the returned pointer.<br /> <br /> This leads to a NULL pointer dereference if devlink allocation fails.<br /> Add a check for a NULL devlink pointer and return NULL early to avoid<br /> the crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: 3com: 3c59x: fix possible null dereference in vortex_probe1()<br /> <br /> pdev can be null and free_ring: can be called in 1297 with a null<br /> pdev.

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mpsse: fix reference leak in gpio_mpsse_probe() error paths<br /> <br /> The reference obtained by calling usb_get_dev() is not released in the<br /> gpio_mpsse_probe() error paths. Fix that by using device managed helper<br /> functions. Also remove the usb_put_dev() call in the disconnect function<br /> since now it will be released automatically.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: frags: drop fraglist conntrack references<br /> <br /> Jakub added a warning in nf_conntrack_cleanup_net_list() to make debugging<br /> leaked skbs/conntrack references more obvious.<br /> <br /> syzbot reports this as triggering, and I can also reproduce this via<br /> ip_defrag.sh selftest:<br /> <br /> conntrack cleanup blocked for 60s<br /> WARNING: net/netfilter/nf_conntrack_core.c:2512<br /> [..]<br /> <br /> conntrack clenups gets stuck because there are skbs with still hold nf_conn<br /> references via their frag_list.<br /> <br /> net.core.skb_defer_max=0 makes the hang disappear.<br /> <br /> Eric Dumazet points out that skb_release_head_state() doesn&amp;#39;t follow the<br /> fraglist.<br /> <br /> ip_defrag.sh can only reproduce this problem since<br /> commit 6471658dc66c ("udp: use skb_attempt_defer_free()"), but AFAICS this<br /> problem could happen with TCP as well if pmtu discovery is off.<br /> <br /> The relevant problem path for udp is:<br /> 1. netns emits fragmented packets<br /> 2. nf_defrag_v6_hook reassembles them (in output hook)<br /> 3. reassembled skb is tracked (skb owns nf_conn reference)<br /> 4. ip6_output refragments<br /> 5. refragmented packets also own nf_conn reference (ip6_fragment<br /> calls ip6_copy_metadata())<br /> 6. on input path, nf_defrag_v6_hook skips defragmentation: the<br /> fragments already have skb-&gt;nf_conn attached<br /> 7. skbs are reassembled via ipv6_frag_rcv()<br /> 8. skb_consume_udp -&gt; skb_attempt_defer_free() -&gt; skb ends up<br /> in pcpu freelist, but still has nf_conn reference.<br /> <br /> Possible solutions:<br /> 1 let defrag engine drop nf_conn entry, OR<br /> 2 export kick_defer_list_purge() and call it from the conntrack<br /> netns exit callback, OR<br /> 3 add skb_has_frag_list() check to skb_attempt_defer_free()<br /> <br /> 2 &amp; 3 also solve ip_defrag.sh hang but share same drawback:<br /> <br /> Such reassembled skbs, queued to socket, can prevent conntrack module<br /> removal until userspace has consumed the packet. While both tcp and udp<br /> stack do call nf_reset_ct() before placing skb on socket queue, that<br /> function doesn&amp;#39;t iterate frag_list skbs.<br /> <br /> Therefore drop nf_conn entries when they are placed in defrag queue.<br /> Keep the nf_conn entry of the first (offset 0) skb so that reassembled<br /> skb retains nf_conn entry for sake of TX path.<br /> <br /> Note that fixes tag is incorrect; it points to the commit introducing the<br /> &amp;#39;ip_defrag.sh reproducible problem&amp;#39;: no need to backport this patch to<br /> every stable kernel.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: lpc18xx-dmamux: fix device leak on route allocation<br /> <br /> Make sure to drop the reference taken when looking up the DMA mux<br /> platform device during route allocation.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.