Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix folio isn&amp;#39;t locked in softleaf_to_folio()<br /> <br /> On arm64 server, we found folio that get from migration entry isn&amp;#39;t locked<br /> in softleaf_to_folio(). This issue triggers when mTHP splitting and<br /> zap_nonpresent_ptes() races, and the root cause is lack of memory barrier<br /> in softleaf_to_folio(). The race is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> deferred_split_scan() zap_nonpresent_ptes()<br /> lock folio<br /> split_folio()<br /> unmap_folio()<br /> change ptes to migration entries<br /> __split_folio_to_order() softleaf_to_folio()<br /> set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry))<br /> smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio))<br /> prep_compound_page() for tail pages<br /> <br /> In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages<br /> are visible before the tail page becomes non-compound. smp_wmb() should<br /> be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a<br /> result, if zap_nonpresent_ptes() accesses migration entry that stores tail<br /> pfn, softleaf_to_folio() may see the updated compound_head of tail page<br /> before page-&gt;flags.<br /> <br /> This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()<br /> because of the race between folio split and zap_nonpresent_ptes()<br /> leading to a folio incorrectly undergoing modification without a folio<br /> lock being held.<br /> <br /> This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further<br /> swapops predicates"), which in merged in v6.19-rc1.<br /> <br /> To fix it, add missing smp_rmb() if the softleaf entry is migration entry<br /> in softleaf_to_folio() and softleaf_to_page().<br /> <br /> [tujinjiang@huawei.com: update function name and comments]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> writeback: don&amp;#39;t block sync for filesystems with no data integrity guarantees<br /> <br /> Add a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot<br /> guarantee data persistence on sync (eg fuse). For superblocks with this<br /> flag set, sync kicks off writeback of dirty inodes but does not wait<br /> for the flusher threads to complete the writeback.<br /> <br /> This replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in<br /> commit f9a49aa302a0 ("fs/writeback: skip AS_NO_DATA_INTEGRITY mappings<br /> in wait_sb_inodes()"). The flag belongs at the superblock level because<br /> data integrity is a filesystem-wide property, not a per-inode one.<br /> Having this flag at the superblock level also allows us to skip having<br /> to iterate every dirty inode in wait_sb_inodes() only to skip each inode<br /> individually.<br /> <br /> Prior to this commit, mappings with no data integrity guarantees skipped<br /> waiting on writeback completion but still waited on the flusher threads<br /> to finish initiating the writeback. Waiting on the flusher threads is<br /> unnecessary. This commit kicks off writeback but does not wait on the<br /> flusher threads. This change properly addresses a recent report [1] for<br /> a suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting<br /> on the flusher threads to finish:<br /> <br /> Workqueue: pm_fs_sync pm_fs_sync_work_fn<br /> Call Trace:<br /> <br /> __schedule+0x457/0x1720<br /> schedule+0x27/0xd0<br /> wb_wait_for_completion+0x97/0xe0<br /> sync_inodes_sb+0xf8/0x2e0<br /> __iterate_supers+0xdc/0x160<br /> ksys_sync+0x43/0xb0<br /> pm_fs_sync_work_fn+0x17/0xa0<br /> process_one_work+0x193/0x350<br /> worker_thread+0x1a1/0x310<br /> kthread+0xfc/0x240<br /> ret_from_fork+0x243/0x280<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> On fuse this is problematic because there are paths that may cause the<br /> flusher thread to block (eg if systemd freezes the user session cgroups<br /> first, which freezes the fuse daemon, before invoking the kernel<br /> suspend. The kernel suspend triggers -&gt;write_node() which on fuse issues<br /> a synchronous setattr request, which cannot be processed since the<br /> daemon is frozen. Or if the daemon is buggy and cannot properly complete<br /> writeback, initiating writeback on a dirty folio already under writeback<br /> leads to writeback_get_folio() -&gt; folio_prepare_writeback() -&gt;<br /> unconditional wait on writeback to finish, which will cause a hang).<br /> This commit restores fuse to its prior behavior before tmp folios were<br /> removed, where sync was essentially a no-op.<br /> <br /> [1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Fix OOB access in ibmvfc_discover_targets_done()<br /> <br /> A malicious or compromised VIO server can return a num_written value in the<br /> discover targets MAD response that exceeds max_targets. This value is<br /> stored directly in vhost-&gt;num_targets without validation, and is then used<br /> as the loop bound in ibmvfc_alloc_targets() to index into disc_buf[], which<br /> is only allocated for max_targets entries. Indices at or beyond max_targets<br /> access kernel memory outside the DMA-coherent allocation. The<br /> out-of-bounds data is subsequently embedded in Implicit Logout and PLOGI<br /> MADs that are sent back to the VIO server, leaking kernel memory.<br /> <br /> Fix by clamping num_written to max_targets before storing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iomap: fix invalid folio access when i_blkbits differs from I/O granularity<br /> <br /> Commit aa35dd5cbc06 ("iomap: fix invalid folio access after<br /> folio_end_read()") partially addressed invalid folio access for folios<br /> without an ifs attached, but it did not handle the case where<br /> 1 cur_folio = NULL;<br /> <br /> in iomap_read_folio_iter() will not invalidate ctx-&gt;cur_folio, and<br /> iomap_read_end() will still be called on the folio even though the IO<br /> helper owns it and will finish the read on it.<br /> <br /> Fix this by unconditionally invalidating ctx-&gt;cur_folio for the !ifs<br /> case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: check contexts-&gt;nr in repeat_call_fn<br /> <br /> damon_sysfs_repeat_call_fn() calls damon_sysfs_upd_tuned_intervals(),<br /> damon_sysfs_upd_schemes_stats(), and<br /> damon_sysfs_upd_schemes_effective_quotas() without checking contexts-&gt;nr. <br /> If nr_contexts is set to 0 via sysfs while DAMON is running, these<br /> functions dereference contexts_arr[0] and cause a NULL pointer<br /> dereference. Add the missing check.<br /> <br /> For example, the issue can be reproduced using DAMON sysfs interface and<br /> DAMON user-space tool (damo) [1] like below.<br /> <br /> $ sudo damo start --refresh_interval 1s<br /> $ echo 0 | sudo tee \<br /> /sys/kernel/mm/damon/admin/kdamonds/0/contexts/nr_contexts

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: check contexts-&gt;nr before accessing contexts_arr[0]<br /> <br /> Multiple sysfs command paths dereference contexts_arr[0] without first<br /> verifying that kdamond-&gt;contexts-&gt;nr == 1. A user can set nr_contexts to<br /> 0 via sysfs while DAMON is running, causing NULL pointer dereferences.<br /> <br /> In more detail, the issue can be triggered by privileged users like<br /> below.<br /> <br /> First, start DAMON and make contexts directory empty<br /> (kdamond-&gt;contexts-&gt;nr == 0).<br /> <br /> # damo start<br /> # cd /sys/kernel/mm/damon/admin/kdamonds/0<br /> # echo 0 &gt; contexts/nr_contexts<br /> <br /> Then, each of below commands will cause the NULL pointer dereference.<br /> <br /> # echo update_schemes_stats &gt; state<br /> # echo update_schemes_tried_regions &gt; state<br /> # echo update_schemes_tried_bytes &gt; state<br /> # echo update_schemes_effective_quotas &gt; state<br /> # echo update_tuned_intervals &gt; state<br /> <br /> Guard all commands (except OFF) at the entry point of<br /> damon_sysfs_handle_cmd().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/sysfs: fix param_ctx leak on damon_sysfs_new_test_ctx() failure<br /> <br /> Patch series "mm/damon/sysfs: fix memory leak and NULL dereference<br /> issues", v4.<br /> <br /> DAMON_SYSFS can leak memory under allocation failure, and do NULL pointer<br /> dereference when a privileged user make wrong sequences of control. Fix<br /> those.<br /> <br /> <br /> This patch (of 3):<br /> <br /> When damon_sysfs_new_test_ctx() fails in damon_sysfs_commit_input(),<br /> param_ctx is leaked because the early return skips the cleanup at the out<br /> label. Destroy param_ctx before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: prevent immediate PASID reuse case<br /> <br /> PASID resue could cause interrupt issue when process<br /> immediately runs into hw state left by previous<br /> process exited with the same PASID, it&amp;#39;s possible that<br /> page faults are still pending in the IH ring buffer when<br /> the process exits and frees up its PASID. To prevent the<br /> case, it uses idr cyclic allocator same as kernel pid&amp;#39;s.<br /> <br /> (cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix drm_edid leak in amdgpu_dm<br /> <br /> [WHAT]<br /> When a sink is connected, aconnector-&gt;drm_edid was overwritten without<br /> freeing the previous allocation, causing a memory leak on resume.<br /> <br /> [HOW]<br /> Free the previous drm_edid before updating it.<br /> <br /> (cherry picked from commit 52024a94e7111366141cfc5d888b2ef011f879e5)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: check if ext_caps is valid in BL setup<br /> <br /> LVDS connectors don&amp;#39;t have extended backlight caps so check<br /> if the pointer is valid before accessing it.<br /> <br /> (cherry picked from commit 3f797396d7f4eb9bb6eded184bbc6f033628a6f6)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: stop reclaim before pushing AIL during unmount<br /> <br /> The unmount sequence in xfs_unmount_flush_inodes() pushed the AIL while<br /> background reclaim and inodegc are still running. This is broken<br /> independently of any use-after-free issues - background reclaim and<br /> inodegc should not be running while the AIL is being pushed during<br /> unmount, as inodegc can dirty and insert inodes into the AIL during the<br /> flush, and background reclaim can race to abort and free dirty inodes.<br /> <br /> Reorder xfs_unmount_flush_inodes() to stop inodegc and cancel background<br /> reclaim before pushing the AIL. Stop inodegc before cancelling<br /> m_reclaim_work because the inodegc worker can re-queue m_reclaim_work<br /> via xfs_inodegc_set_reclaimable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/pagewalk: fix race between concurrent split and refault<br /> <br /> The splitting of a PUD entry in walk_pud_range() can race with a<br /> concurrent thread refaulting the PUD leaf entry causing it to try walking<br /> a PMD range that has disappeared.<br /> <br /> An example and reproduction of this is to try reading numa_maps of a<br /> process while VFIO-PCI is setting up DMA (specifically the<br /> vfio_pin_pages_remote call) on a large BAR for that process.<br /> <br /> This will trigger a kernel BUG:<br /> vfio-pci 0000:03:00.0: enabling device (0000 -&gt; 0002)<br /> BUG: unable to handle page fault for address: ffffa23980000000<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> ...<br /> RIP: 0010:walk_pgd_range+0x3b5/0x7a0<br /> Code: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24<br /> 28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 f7 06<br /> 9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74<br /> RSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287<br /> RAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff<br /> RDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0<br /> RBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000<br /> R10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000<br /> R13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000<br /> FS: 00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> __walk_page_range+0x195/0x1b0<br /> walk_page_vma+0x62/0xc0<br /> show_numa_map+0x12b/0x3b0<br /> seq_read_iter+0x297/0x440<br /> seq_read+0x11d/0x140<br /> vfs_read+0xc2/0x340<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x68/0x130<br /> ? get_page_from_freelist+0x5c2/0x17e0<br /> ? mas_store_prealloc+0x17e/0x360<br /> ? vma_set_page_prot+0x4c/0xa0<br /> ? __alloc_pages_noprof+0x14e/0x2d0<br /> ? __mod_memcg_lruvec_state+0x8d/0x140<br /> ? __lruvec_stat_mod_folio+0x76/0xb0<br /> ? __folio_mod_stat+0x26/0x80<br /> ? do_anonymous_page+0x705/0x900<br /> ? __handle_mm_fault+0xa8d/0x1000<br /> ? __count_memcg_events+0x53/0xf0<br /> ? handle_mm_fault+0xa5/0x360<br /> ? do_user_addr_fault+0x342/0x640<br /> ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0<br /> ? irqentry_exit_to_user_mode+0x24/0x100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fe88464f47e<br /> Code: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f<br /> 84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 3d 00<br /> f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28<br /> RSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e<br /> RDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003<br /> RBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000<br /> R10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000<br /> <br /> <br /> Fix this by validating the PUD entry in walk_pmd_range() using a stable<br /> snapshot (pudp_get()). If the PUD is not present or is a leaf, retry the<br /> walk via ACTION_AGAIN instead of descending further. This mirrors the<br /> retry logic in walk_pte_range(), which lets walk_pmd_range() retry if the<br /> PTE is not being got by pte_offset_map_lock().