Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/damon/mtier: error out for zero quota goal target values<br /> <br /> Patch series "mm/damon: avoid division by zero from damos_quota_score()".<br /> <br /> DAMON_SAMPLE_MTIER and DAMON_LRU_SORT allow the user to trigger division<br /> by zero in damos_quota_score(). Avoid it by adding parameters validation<br /> checks.<br /> <br /> <br /> This patch (of 2):<br /> <br /> damos_quota_score() can trigger division by zero if the target_value is<br /> zero. DAMON_SAMPLE_MTIER lets users set the target_value via<br /> node0_mem_{used,free}_bp parameters. It doesn&amp;#39;t guard zero value case,<br /> though. As a result, users can trigger division by zero. Fix the issue<br /> by returning an error when the user tries to start DAMON with zero<br /> node0_mem_{used,free}_bp parameter values.<br /> <br /> DAMON_SAMPLE_MTIER is just a sample module, but the consequence is quite<br /> bad. Also the zero node0_mem_free_bp parameter might look like a<br /> reasonable setup to some users. Hence, the issue might really happen in<br /> the real world.<br /> <br /> One reliable way to reproduce the issue is like below:<br /> <br /> # cd /sys/module/damon_sample_mtier/parameters<br /> # echo 4096 &gt; node0_start_addr<br /> # echo 8192 &gt; node0_end_addr<br /> # echo 8192 &gt; node1_start_addr<br /> # echo 81920 &gt; node1_end_addr<br /> # echo 0 &gt; node0_mem_free_bp<br /> # echo Y &gt; enabled<br /> # dmesg -w<br /> [...]<br /> [18792.235916] Oops: divide error: 0000 [#1] SMP NOPTI<br /> [...]<br /> [18792.242787] RIP: 0010:damos_quota_score+0x6f/0x480<br /> [...]<br /> <br /> This issue was discovered [1] by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/lru_sort: error out for &gt;10000 active_mem_bp<br /> <br /> damos_quota_score() can trigger division by zero if the target value is<br /> zero. DAMON_LRU_SORT lets users set the target value for the hot memory<br /> scheme via active_mem_bp parameter. It avoids setting it as the target<br /> value if the parameter value is zero. However, it also sets the cold<br /> memory scheme with a target value that is calculated as &amp;#39;10000 -<br /> active_mem_bp + 2&amp;#39;. Hence, if a user sets active_mem_bp 10002, the cold<br /> memory scheme&amp;#39;s quota goal target value can be zero. As a result,<br /> division by zero can be triggered. Fix by returning an error when the<br /> user tries to start DAMON with &gt;10000 active_mem_bp parameter value.<br /> <br /> It makes no sense to set active_mem_bp with 10002. It also requires<br /> module parameters write permission to reproduce the issue. That said, the<br /> consequence is quite bad.<br /> <br /> One reliable way to reproduce the issue is like below:<br /> <br /> # cd /sys/module/damon_lru_sort/parameters<br /> # echo 1000 &gt; wmarks_high<br /> # echo 995 &gt; wmarks_mid<br /> # echo 0 &gt; wmarks_low<br /> # echo 10002 &gt; active_mem_bp<br /> # echo Y &gt; enabled<br /> # dmesg -w<br /> [...]<br /> [ 597.421247] Oops: divide error: 0000 [#1] SMP NOPTI<br /> [ 597.428848] RIP: 0010:damos_quota_score+0x6f/0x480<br /> <br /> This issue was discovered [1] by Sashiko.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: take fl-&gt;lock when moving mmaps on interrupted invoke<br /> <br /> When an invoke is interrupted by a signal,<br /> wait_for_completion_interruptible() returns -ERESTARTSYS and<br /> fastrpc_internal_invoke() moves every buffer from fl-&gt;mmaps onto<br /> cctx-&gt;invoke_interrupted_mmaps. This list_del()/list_add_tail() walk<br /> runs without holding fl-&gt;lock, the lock that serialises fl-&gt;mmaps in<br /> fastrpc_req_mmap() and fastrpc_req_munmap() everywhere else.<br /> <br /> Take fl-&gt;lock around the move, matching every other fl-&gt;mmaps accessor.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: bound the hwdep mmap fault offset<br /> <br /> snd_us428ctls_vm_fault() turns the faulting page offset into a kernel<br /> address with no bound of any kind:<br /> <br /> offset = vmf-&gt;pgoff page = page;<br /> <br /> return 0;<br /> <br /> snd_us428ctls_mmap() checks only the length of the mapping, never the<br /> offset, and us428ctls_sharedmem is a single page from<br /> alloc_pages_exact(). For a character device file_mmap_size_max()<br /> returns ULONG_MAX, so the mm layer imposes no ceiling either. Every page<br /> offset above zero resolves to a struct page outside the object, and the<br /> handler installs it into the caller&amp;#39;s address space read-write; the vma<br /> is not marked read-only.<br /> <br /> The caller picks the page frame with a single mmap() argument and gets<br /> read-write access to a page of kernel memory it does not own; an offset<br /> that lands in an unpopulated vmemmap region oopses instead.<br /> <br /> A process that can open the hwdep node of an attached US-X2Y reaches<br /> this after loading the FPGA image through the same node; no capability<br /> check is involved.<br /> <br /> On 7.2.0-rc5 (arm64), mmap() with a large offset:<br /> <br /> Unable to handle kernel paging request at virtual address fffffdffc45d5ac8<br /> pc : snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]<br /> Call trace:<br /> snd_us428ctls_vm_fault+0x68/0x140 [snd_usb_usx2y]<br /> __do_fault<br /> __handle_mm_fault<br /> handle_mm_fault<br /> el0_da<br /> <br /> Reject any offset outside the shared region. The pcm hwdep handler in<br /> usx2yhwdeppcm.c computes its address the same way and needs the same<br /> bound.<br /> <br /> Discovered by XBOW, triaged by Baul Lee

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/ops-common: putback folios on invalid migrate nid<br /> <br /> damon_pa_migrate() and damos_va_migrate() isolate folios into a local list<br /> and then call damon_migrate_pages(). When target_nid is invalid<br /> (including the scheme default NUMA_NO_NODE / -1), damon_migrate_pages()<br /> returns early without putting the folios back to the LRU.<br /> <br /> Callers then discard the list head while those folios remain isolated with<br /> an extra reference taken by folio_isolate_lru(). The pages stay off the<br /> LRU for as long as the mapping exists (anon active+inactive counts drop<br /> while RSS does not), and the leftover references can pin the pages after<br /> the mapping is gone.<br /> <br /> Put the folios back on the invalid-nid path so ignored migration requests<br /> still return them to the LRU.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix NULL pointer dereference in module event cache removal<br /> <br /> A module-only event filter such as ":mod:foo" is cached with a NULL<br /> event_mod-&gt;match when foo has not been loaded. If a later write tries to<br /> remove a specific match from the same module, remove_cache_mod() passes<br /> the NULL cached match to strcmp(), causing a NULL pointer dereference.<br /> <br /> The issue can be reproduced from userspace:<br /> <br /> echo &amp;#39;:mod:trace_events_kunit_missing&amp;#39; &gt; /sys/kernel/tracing/set_event<br /> echo &amp;#39;!foo_bar:mod:trace_events_kunit_missing&amp;#39; &gt;&gt; /sys/kernel/tracing/set_event<br /> <br /> The second write must be a concatenation ("&gt;&gt;") to not include O_TRUNC as<br /> that would cause ftrace_clear_events() to clear the cached modules lines.<br /> <br /> The crash was reproduced on x86_64 QEMU while KUnit workers contended on<br /> the event tracing path:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> RIP: 0010:strcmp+0x10/0x30<br /> Call Trace:<br /> __ftrace_set_clr_event_nolock+0x373/0x4a0<br /> ftrace_set_clr_event+0xf0/0x180<br /> ftrace_event_write+0xdf/0x110<br /> vfs_write+0xf6/0x440<br /> ksys_write+0x68/0xe0<br /> do_syscall_64+0xf9/0x540<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Check event_mod-&gt;match before comparing it, consistent with the existing<br /> NULL checks for the cached system and event fields. The mismatched removal<br /> continues to return -EINVAL; a broad cached module filter is removed with<br /> "!:mod:".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Prevent subbuf order change when resizing is disabled<br /> <br /> Because ring_buffer_subbuf_order_set() frees buffer pages, we can&amp;#39;t<br /> allow it when resizing is disabled. A non-consuming reader is at risk of<br /> use-after-free (rb_advance_iter()).<br /> <br /> Return -EBUSY on resize_disabled, matching ring_buffer_resize()<br /> behaviour.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: bitblit: bound-check glyph index in bit_cursor()<br /> <br /> bit_cursor() fetches the glyph under the cursor with<br /> <br /> c = scr_readw(vc_pos);<br /> src = vc_font.data + ((c &amp; charmask) * w * height);<br /> <br /> where charmask is 0x1ff when vc_hi_font_mask is set. The screen buffer<br /> value comes directly from scr_readw() and may be larger than the current<br /> font&amp;#39;s glyph count.<br /> <br /> Syzkaller triggers this via vcs_write(). The Call Trace shows<br /> vcs_write() in vc_screen.c writing an arbitrary 16-bit value with<br /> writev() to /dev/vcsa, which vcs_write_buf() in vc_screen.c stores via<br /> vcs_scr_writew() without checking charcount. The stored value is later<br /> read in bit_cursor() in bitblit.c.<br /> <br /> When the font is changed from a font with 512 glyphs to a font with<br /> 256 glyphs, the screen buffer can retain characters with the high<br /> bit set from the previous mode, which could also produce the same<br /> out-of-bounds access.<br /> <br /> BUG: KASAN: global-out-of-bounds in soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70<br /> Read of size 16 at addr ffff800086c57970<br /> <br /> Call Trace:<br /> soft_cursor+0x378/0x6bc drivers/video/fbdev/core/softcursor.c:70<br /> bit_cursor+0xa90/0x1108 drivers/video/fbdev/core/bitblit.c:365<br /> fbcon_cursor+0x344/0x498 drivers/video/fbdev/core/fbcon.c:1427<br /> hide_cursor+0xdc/0x2d0 drivers/tty/vt/vt.c:883<br /> update_region+0x100/0x18c drivers/tty/vt/vt.c:669<br /> vcs_write+0x8ec/0xaf0 drivers/tty/vt/vc_screen.c:685<br /> <br /> bit_putcs_aligned() and bit_putcs_unaligned() already clamp the glyph<br /> index to vc_font.charcount. Apply the same clamp in bit_cursor() after<br /> extracting the attribute and masking, before indexing fontdata.<br /> <br /> The fix completes the bounds checking started in commit 18c4ef4e765a<br /> ("fbdev: bitblit: bound-check glyph index in bit_putcs*"), which missed<br /> the cursor path.<br /> <br /> This change should be safe because the clamp reuses the existing<br /> contract from fbcon: charcount is maintained under console_lock in<br /> con_font_set() and fbcon_font_set(), and hi_font_mask is cleared when<br /> switching from 512 to 256 glyphs. When stale screen data with high bits<br /> remains after a font switch, or when vcs_write() stores an arbitrary<br /> value, clamping the index to 0 prevents the out-of-bounds read without<br /> changing cursor semantics — the same fallback bit_putcs uses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race between update_event_fields and, event_define_fields<br /> <br /> The following sequence may leads race between event_define_fields()<br /> and update_event_fields():<br /> <br /> CPU0 (loads module A) CPU1 (loads module B)<br /> =============================== ===============================<br /> load_module(A) load_module(B)<br /> notifier_call_chain notifier_call_chain<br /> trace_module_notify trace_module_notify<br /> mutex_lock(&amp;event_mutex) trace_event_update_all()<br /> trace_module_add_events(A) down_write(&amp;trace_event_sem)<br /> __register_event(call_A)<br /> __add_event_to_tracers(call_A)<br /> event_define_fields(call_A)<br /> for each f: list_for_each_entry(field,<br /> list_add(&amp;f-&gt;link, &amp;class-&gt;fields, link)<br /> &amp;class-&gt;fields) field = class-&gt;fields-&gt;next;<br /> <br /> Where access to the class-&gt;fields is not protected by the event_mutex in<br /> trace_event_update_all().<br /> <br /> This produces the following panic:<br /> Unable to handle kernel access ... at virtual address 0000000000000018<br /> pc : update_event_fields+0xf8/0x368<br /> Call trace:<br /> update_event_fields+0xf8/0x368<br /> trace_event_update_all+0x7c/0x2b4<br /> trace_module_notify+0x4c/0x1dc<br /> notifier_call_chain+0x84/0x168<br /> blocking_notifier_call_chain_robust+0x64/0xd4<br /> load_module+0x10c8/0x123c<br /> __arm64_sys_finit_module+0x230/0x31c<br /> <br /> Fix by taking event_mutex in trace_event_update_all() before<br /> trace_event_sem.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: smc: fix splice entry lifetime imbalance in smc_rx_splice<br /> <br /> smc_rx_splice() passes pages to splice_to_pipe() before taking the<br /> references that cover the lifetime of each splice entry. In the<br /> VM-backed RMB path, splice_to_pipe() may drop unqueued entries through<br /> smc_rx_spd_release(), while queued entries are released later via the<br /> pipe buffer callback.<br /> <br /> The old post-splice accounting also derives the number of queued VM pages<br /> from an offset mutated while building the descriptor, and a multi-page<br /> splice pairs one sock_hold() with multiple sock_put() calls.<br /> <br /> Take the page and socket references for every candidate entry before<br /> splice_to_pipe(), and drop the matching private state, page reference,<br /> and socket reference from smc_rx_spd_release() for entries that never<br /> get queued. This fixes a refcount imbalance that can underflow page<br /> refcounts and trigger a use-after-free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/huge_memory: fix huge_zero_pfn race<br /> <br /> Patch series "mm/huge_memory: fix huge_zero_pfn race", v2.<br /> <br /> There is a subtle race in the reference-counted huge_zero_folio<br /> implementation.<br /> <br /> The fast path atomic logic fails to account for the fact that the shrinker<br /> (which drops the final huge_zero_refcount pin) can overwrite huge_zero_pfn<br /> with the ~0UL sentinel value in shrink_huge_zero_folio_scan() after a<br /> racing get_huge_zero_folio() installed a valid value there.<br /> <br /> This results in huge_zero_folio being correctly set but huge_zero_pfn<br /> being set incorrectly and thus is_huge_zero_pfn() and consequently<br /> is_huge_zero_pmd() will misidentify the huge zero folio as being an<br /> ordinary THP folio.<br /> <br /> This can result in the huge zero folio being split and otherwise treated<br /> incorrectly.<br /> <br /> The solution to this is very subtle as there is an atomic fast path, and<br /> thus ordering in weakly ordered architectures has to be treated very<br /> carefully.<br /> <br /> The first commit fixes the issue by introducing a spinlock around<br /> huge_zero_[pfn, folio, refcount] write, with careful consideration paid to<br /> load/store ordering in the fast path. It is placed first and kept as<br /> small as possible so that it can be backported on its own.<br /> <br /> The second commit is a pure cleanup which reworks the<br /> CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic to better separate the persistent<br /> logic from the dynamically allocated one.<br /> <br /> <br /> This patch (of 2):<br /> <br /> If !CONFIG_PERSISTENT_HUGE_ZERO_FOLIO, the huge_zero_folio is refcounted<br /> by huge_zero_refcount and returned by mm_get_huge_zero_folio().<br /> <br /> When the caller is done with the huge zero page, its reference count is<br /> decremented. Only a shrinker can set the reference count to zero.<br /> <br /> A race can unfortunately occur between a shrinker decrementing the<br /> reference count to zero and a concurrent page fault.<br /> <br /> This is because shrink_huge_zero_folio_scan() might, if very unlucky, be<br /> preempted between setting huge_zero_refcount to zero and writing an<br /> invalid value.<br /> <br /> During this time get_huge_zero_folio() could write to huge_zero_pfn before<br /> shrink_huge_zero_folio_scan() resumes.<br /> <br /> In this event the huge zero folio will be persistently misidentified<br /> causing the THP code path to be entered inappropriately for the huge zero<br /> folio:<br /> <br /> CPU 0 CPU 1<br /> =======================================|=================================<br /> shrink_huge_zero_folio_scan() |<br /> atomic_cmpxchg() sets refcount to 0 |<br /> xchg() sets huge_zero_folio to NULL | get_huge_zero_folio()<br /> | | atomic_inc_not_zero() -&gt; zero<br /> preempted for a long time | Allocate new huge zero folio<br /> | | Write valid huge_zero_folio<br /> v | Write valid huge_zero_pfn<br /> Overwrite huge_zero_pfn with ~0UL

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix group leader use-after-free after sibling detach<br /> <br /> perf_group_detach() handles leader and sibling detach differently. When the<br /> group leader is detached, all siblings are promoted to singleton events and<br /> their group_leader pointer is reset to themselves. When a sibling is<br /> detached, it is removed from the leader&amp;#39;s sibling_list, but its<br /> group_leader pointer is left pointing at the old leader.<br /> <br /> That is harmless when the sibling is being closed and freed immediately, as<br /> in the DETACH_DEAD path. It is not safe when the sibling is detached but<br /> kept alive, such as during CPU hotplug with DETACH_GROUP. In that case the<br /> sibling is removed from the context, while its file descriptor can still<br /> keep it alive.<br /> <br /> A typical failing sequence is:<br /> <br /> - A group contains leader L and sibling S.<br /> - CPU hot-unplug detaches S with DETACH_GROUP, removing it from<br /> L-&gt;sibling_list but leaving S-&gt;group_leader == L.<br /> - L is later closed and freed.<br /> - A PERF_IOC_FLAG_GROUP ioctl on S follows S-&gt;group_leader and<br /> dereferences the freed leader.<br /> <br /> This was reproduced by running the perf event fuzzer, CPU hotplug, and a<br /> stress workload concurrently:<br /> <br /> Unable to handle kernel paging request at virtual address 006b6b6b6b6b6cdb<br /> CPU: 2 PID: 12489 Comm: perf_fuzzer 6.18.7 PREEMPT<br /> pc : perf_ioctl+0x34c/0xc68<br /> x20: ffffff89a3fa2c70 x8 : 6b6b6b6b6b6b6b6b<br /> Code: 943c4a0e 340047a0 f9404a94 f9411e88 (f940b908)<br /> Call trace:<br /> perf_ioctl+0x34c/0xc68 (P)<br /> __arm64_sys_ioctl+0xa0/0xf4<br /> invoke_syscall+0x58/0xe4<br /> el0_svc_common+0xa8/0xdc<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x40/0xc0<br /> el0t_64_sync_handler+0x68/0xdc<br /> el0t_64_sync+0x1c4/0x1c8<br /> <br /> The fault happened in perf_ioctl(), where perf_event_for_each() follows<br /> the stale group_leader pointer and perf_event_for_each_child() then<br /> dereferences the freed leader&amp;#39;s context.<br /> <br /> Fix the use-after-free by promoting the detached sibling to a singleton.<br /> Also fix __event_disable() cgroup accounting and event state change.