Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atlantic: free RX pages of consumed but not refilled buffers<br /> <br /> aq_ring_rx_deinit() only walks [sw_head, sw_tail), the region posted to<br /> hardware. Since the page reuse strategy was added, a cleaned RX buffer<br /> keeps its page (and its DMA mapping) in the ring for reuse, and refill<br /> is batched: aq_ring_rx_fill() returns early until AQ_CFG_RX_REFILL_THRES<br /> slots are free. Slots that were consumed but not yet reposted therefore<br /> sit in the complementary [sw_tail, sw_head) gap with a live page, and<br /> the deinit walk never visits them: up to a refill batch worth of pages<br /> and DMA mappings leak on every interface down.<br /> <br /> Walk the whole ring instead and release whatever is still there. Also<br /> bail out if the buffer ring is already gone: a partial<br /> aq_ptp_ring_alloc() failure frees the ring but leaves aq_nic set, so<br /> aq_ptp_ring_deinit() still gets here on the unwind path.

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent in6_dev_get() from resurrecting inet6_dev<br /> <br /> in6_dev_get() reads dev-&gt;ip6_ptr under RCU and then unconditionally<br /> increments its refcount. Device teardown can clear the pointer and drop<br /> the last reference between these operations. The increment then<br /> resurrects an object whose RCU free has already been queued, so callers<br /> can use it after it is freed.<br /> <br /> Use refcount_inc_not_zero() and return NULL when the object has already<br /> reached zero. RCU keeps the memory accessible through the attempted<br /> reference acquisition, and a successful increment pins the object for<br /> the caller.<br /> <br /> An independent run on the exact unpatched 6f5156d7a31a (v7.2-rc3)<br /> kernel reproduced the invalid reference acquisition as UID 1000:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> ip6_mc_source+0xef4/0x17e0<br /> <br /> It was followed by the corresponding reference underflow in<br /> ip6_mc_source(). The supplied trace from the same unpatched revision<br /> additionally shows the access after the RCU read-side section ends:<br /> <br /> BUG: KASAN: slab-use-after-free in mutex_lock+0x76/0xe0<br /> Write of size 8 at addr ffff888015b50240 by task poc/1219<br /> <br /> Bug found and triaged by OpenAI Security Research and<br /> validated by Trail of Bits.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: atlantic: free stranded TX buffers on ring deinit<br /> <br /> aq_vec_deinit() drains the TX rings with a single aq_ring_tx_clean()<br /> call, which frees at most AQ_CFG_TX_CLEAN_BUDGET (256) descriptors and<br /> stops at hw_head, which no longer moves once aq_vec_stop() has stopped<br /> the hardware and NAPI. Completed descriptors beyond the budget and<br /> everything still posted in [hw_head, sw_tail) keep their skb or<br /> xdp_frame when the interface goes down: aq_vec_ring_free() then frees<br /> the buffer ring and the references are lost for good.<br /> <br /> Today this is a silent memory leak on every interface down under<br /> TX/XDP_TX load. With the conversion of the RX path to page_pool posted<br /> for net-next it becomes much more visible: XDP_TX frames carry fragment<br /> references on the RX ring&amp;#39;s page_pool, so a single stranded frame keeps<br /> the pool&amp;#39;s inflight count above zero forever. page_pool_destroy() then<br /> never completes, the pool is leaked together with its pages, and<br /> "page_pool_release_retry() stalled pool shutdown" is warned every 60<br /> seconds from that point on, on every ifdown, XDP detach or ring resize<br /> under XDP_TX load.<br /> <br /> Bring back aq_ring_tx_deinit() as it was before the removal and use it<br /> for teardown again, with one extension: TX rings can hold xdp_frames<br /> nowadays, so release those too. They are returned with<br /> xdp_return_frame() since this runs in process context.

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