Vulnerabilidades

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

*** 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 /> 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 /> netfilter: nf_conntrack: defer invalid log until after unlock<br /> <br /> TCP and SCTP conntrack paths can emit invalid-packet logs while ct-&gt;lock<br /> is still held.<br /> <br /> When invalid logging is routed to nfnetlink_log and conntrack export is<br /> enabled, the log path can re-enter conntrack netlink glue and dump the<br /> same conntrack again. Protocol attribute dumping may take ct-&gt;lock, so<br /> logging while holding that lock can deadlock.<br /> <br /> Defer the TCP invalid logs by storing only the minimal log context while<br /> ct-&gt;lock is held and emitting the log after unlocking. Also make the TCP<br /> timeout-lowering invalid path return whether a log is needed, then emit<br /> that log after unlocking.<br /> <br /> Do the same for the SCTP invalid state-transition log that can be reached<br /> while ct-&gt;lock is held.<br /> <br /> Add a lockdep assertion to nf_ct_l4proto_log_invalid() so future callers<br /> that log invalid conntracks while holding ct-&gt;lock are caught outside TCP<br /> and SCTP as well.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: bridge: release template ct on non-IP path<br /> <br /> A bridge nftables ct zone set rule can attach a conntrack template to<br /> an skb before nf_ct_bridge_pre() sees it. For non-IPv4 and non-IPv6<br /> EtherTypes, nf_ct_bridge_pre() currently overwrites skb-&gt;_nfct with<br /> IP_CT_UNTRACKED without releasing the existing template reference.<br /> <br /> That makes the per-cpu template, and any temporary templates allocated<br /> for concurrent use, unreachable and leaks memory until the host runs out<br /> of slab.<br /> <br /> Reset the skb conntrack state before marking the frame untracked so the<br /> existing template reference is dropped on the non-IP path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: ntb_netdev: Preserve RX queue depth on allocation failure<br /> <br /> ntb_netdev_rx_handler() hands the received skb to the network stack<br /> before allocating its replacement. If the allocation fails, nothing is<br /> reposted. Every failure therefore takes one buffer out of the RX queue<br /> while the interface remains up, and enough failures eventually stall<br /> reception.<br /> <br /> A retry path could refill the queue later, but ntb_netdev has none.<br /> Allocate the replacement first instead. If that fails, drop the packet<br /> and repost the same skb. This keeps the queue full and lets packet<br /> delivery resume as soon as memory is available again.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: devmem: prevent net-iov / page mixing<br /> <br /> We should either have net_iov or page backed frags in a single skb,<br /> otherwise it blows up down the stack. Don&amp;#39;t allow mixing in<br /> zerocopy_fill_skb_from_devmem().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: fix use-after-free of the socket by its timers<br /> <br /> The x25 timers are armed with mod_timer() and cancelled with<br /> timer_delete(), so a pending timer holds no reference on the socket and a<br /> cancel does not wait for a callback already running on another CPU.<br /> <br /> x25_heartbeat_expiry() also rearms unconditionally, so it can reinstall<br /> sk-&gt;sk_timer after __x25_destroy_socket() has passed its cancel point.<br /> The following __sock_put() frees the socket while the timer is still<br /> queued, and the next expiry uses freed memory. KASAN reports a<br /> slab-use-after-free on the kmalloc-2k object freed by close().<br /> <br /> timer_delete_sync() cannot be used here: x25_heartbeat_expiry() and<br /> x25_timer_expiry() both reach the cancels from inside the timer they<br /> would wait on, through __x25_destroy_socket() and x25_disconnect().<br /> <br /> Arm the timers with sk_reset_timer() and cancel them with sk_stop_timer()<br /> so that an armed timer owns a reference, and release it in both expiry<br /> handlers. Rearm the heartbeat only while sk_hashed(sk) is still true,<br /> since __x25_destroy_socket() unlinks the socket before dropping it. Arm<br /> the deferred destroy timer the same way and drop its reference in<br /> x25_destroy_timer().<br /> <br /> Reproduced on net with KASAN, with the heartbeat period shortened so the<br /> window recurs. With this patch the reproducer no longer triggers a<br /> report and /proc/net/x25 drains.<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 /> net/dibs: Correct freeing of dmb_clientid_arr<br /> <br /> A dibs device interrupt handler can be active after dibs_dev_del() and<br /> may still access dmb_clientid_arr. (UAF)<br /> <br /> In case of a failure in dibs_dev_add() being called by dibs_lo_dev_probe()<br /> dmb_clientid_arr is freed twice (double free).<br /> <br /> Free dmb_clientid_arr in dibs_dev_release() after last reference is gone.<br /> Note that allocating in dibs_dev_add() instead of dibs_dev_alloc() is ok<br /> for now, because no dmbs can be registered before dibs_dev_add().