Vulnerabilidades

*** Pendiente de traducción *** A vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 2.6.0 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation<br /> <br /> walk_s1() and kvm_walk_nested_s2() expect to be called while holding<br /> kvm-&gt;srcu to guard against memslot changes. While this is generally<br /> the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the<br /> respective walkers without taking kvm-&gt;srcu.<br /> <br /> Fix by acquiring kvm-&gt;srcu prior to the table walk in both instances.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer<br /> <br /> In iso_sock_rebind_bc(), the bis pointer is cached, then the socket lock is<br /> dropped:<br /> bis = iso_pi(sk)-&gt;conn-&gt;hcon;<br /> /* Release the socket before lookups since that requires hci_dev_lock<br /> * which shall not be acquired while holding sock_lock for proper<br /> * ordering.<br /> */<br /> release_sock(sk);<br /> hci_dev_lock(bis-&gt;hdev);<br /> <br /> During the unlocked window, could a concurrent close() destroy the connection<br /> and free the bis structure, causing hci_dev_lock(bis-&gt;hdev) to access memory<br /> after it is freed, fix this by using the hdev reference which was safely<br /> acquired via iso_conn_get_hdev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: mcast: Fix use-after-free when processing MLD queries<br /> <br /> When processing an MLD query, a pointer to the multicast group address<br /> is retrieved when initially parsing the packet. This pointer is later<br /> dereferenced without being reloaded despite the fact that the skb header<br /> might have been reallocated following the pskb_may_pull() calls, leading<br /> to a use-after-free [1].<br /> <br /> Fix by copying the multicast group address when the packet is initially<br /> parsed.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in __mld_query_work (net/ipv6/mcast.c:1512)<br /> Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118<br /> <br /> Workqueue: mld mld_query_work<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)<br /> print_address_description.constprop.0 (mm/kasan/report.c:378)<br /> print_report (mm/kasan/report.c:482)<br /> kasan_report (mm/kasan/report.c:595)<br /> __mld_query_work (net/ipv6/mcast.c:1512)<br /> mld_query_work (net/ipv6/mcast.c:1563)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)<br /> <br /> <br /> [...]<br /> <br /> Freed by task 118:<br /> kasan_save_stack (mm/kasan/common.c:57)<br /> kasan_save_track (mm/kasan/common.c:78)<br /> kasan_save_free_info (mm/kasan/generic.c:584)<br /> __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)<br /> kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)<br /> pskb_expand_head (net/core/skbuff.c:2335)<br /> __pskb_pull_tail (net/core/skbuff.c:2878 (discriminator 4))<br /> __mld_query_work (net/ipv6/mcast.c:1495 (discriminator 1))<br /> mld_query_work (net/ipv6/mcast.c:1563)<br /> process_one_work (kernel/workqueue.c:3314)<br /> worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478)<br /> kthread (kernel/kthread.c:436)<br /> ret_from_fork (arch/x86/kernel/process.c:158)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix sleep-inside-lock in __smc_setsockopt() causing local DoS<br /> <br /> A logic flaw in __smc_setsockopt() allows a local unprivileged user to<br /> cause a Denial of Service (DoS) by holding the socket lock indefinitely.<br /> <br /> The function __smc_setsockopt() calls copy_from_sockptr() while holding<br /> lock_sock(sk). By passing a userfaultfd-monitored memory page (or<br /> FUSE-backed memory on systems where unprivileged userfaultfd is disabled)<br /> as the optval, an attacker can halt execution during the copy operation,<br /> keeping the lock held.<br /> <br /> Combined with asynchronous tear-down operations like shutdown(), this<br /> exhausts the kernel wq (kworkers) and triggers the hung task watchdog.<br /> <br /> [ 240.123456] INFO: task kworker/u8:2 blocked for more than 120 seconds.<br /> [ 240.123489] Call Trace:<br /> [ 240.123501] smc_shutdown+...<br /> [ 240.123512] lock_sock_nested+...<br /> <br /> This patch moves the user-space copy outside the lock_sock() critical<br /> section to prevent the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: optee: prevent use-after-free when the client exits before the supplicant<br /> <br /> Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the<br /> client wait as killable so it can be interrupted during shutdown or<br /> after a supplicant crash. This changes the original lifetime expectations:<br /> the client task can now terminate while the supplicant is still processing<br /> its request.<br /> <br /> If the client exits first it removes the request from its queue and<br /> kfree()s it, while the request ID remains in supp-&gt;idr. A subsequent<br /> lookup on the supplicant path then dereferences freed memory, leading to<br /> a use-after-free.<br /> <br /> Serialise access to the request with supp-&gt;mutex:<br /> <br /> * Hold supp-&gt;mutex in optee_supp_recv() and optee_supp_send() while<br /> looking up and touching the request.<br /> * Let optee_supp_thrd_req() notice that the client has terminated and<br /> signal optee_supp_send() accordingly.<br /> <br /> With these changes the request cannot be freed while the supplicant still<br /> has a reference, eliminating the race.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix use-after-free on sbi-&gt;sync_decompress<br /> <br /> z_erofs_decompress_kickoff() can race with filesystem unmount, causing<br /> a use-after-free on sbi-&gt;sync_decompress.<br /> <br /> When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff()<br /> to queue z_erofs_decompressqueue_work() asynchronously. Then, after all<br /> folios are unlocked, unmount workflow can proceed and sbi will be freed<br /> before accessing to sbi-&gt;sync_decompress.<br /> <br /> Thread (unmount) I/O completion kworker<br /> queue_work<br /> z_erofs_decompressqueue_work<br /> (all folios are unlocked)<br /> cleanup_mnt<br /> ..<br /> erofs_kill_sb<br /> erofs_sb_free<br /> kfree(sbi)<br /> access sbi-&gt;sync_decompress // UAF!!

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix NULL-deref of opinfo-&gt;conn in oplock/lease break notifiers<br /> <br /> smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo-&gt;conn<br /> into a local with neither READ_ONCE() nor a NULL check. Both run from<br /> oplock_break() after opinfo_get_list() has dropped ci-&gt;m_lock, so a<br /> concurrent SMB2 LOGOFF (session_fd_check()) can set op-&gt;conn = NULL<br /> under ci-&gt;m_lock within that window. ksmbd_conn_r_count_inc(conn) then<br /> writes through NULL at offset 0xc4 -- a remotely triggerable oops.<br /> <br /> Guard both reads the way compare_guid_key() already does: read<br /> opinfo-&gt;conn with READ_ONCE() and return early if it is NULL, before<br /> allocating the work struct so nothing leaks. A NULL conn means the<br /> client is gone and the break is moot, so return 0; oplock_break() treats<br /> that as success and runs the normal teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvs: clear the svc scheduler ptr early on edit<br /> <br /> ip_vs_edit_service() while unbinding the old scheduler clears<br /> the svc-&gt;scheduler ptr after the scheduler module initiates<br /> RCU callbacks. This can cause packets to use the old<br /> scheduler at the time when svc-&gt;sched_data is already freed<br /> after RCU grace period.<br /> <br /> Fix it by clearing the ptr early in ip_vs_unbind_scheduler(),<br /> before the done_service method schedules any RCU callbacks.<br /> <br /> Also, if the new scheduler fails to initialize when replacing<br /> the old scheduler, try to restore the old scheduler while still<br /> returning the error code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: add mutex to guard hook reference counting<br /> <br /> As the synproxy infrastructure register netfilter hooks on-demand when a<br /> user adds the first iptables target or nftables expression, if done<br /> concurrently they can race each other.<br /> <br /> Introduce a mutex to serialize the refcount control blocks access from<br /> both frontends. While a per namespace mutex might be more efficient, it<br /> is not needed for target/expression like SYNPROXY.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack_irc: fix possible out-of-bounds read<br /> <br /> When parsing fails after we&amp;#39;ve matched the command string we<br /> should bail out instead of trying to match a different command.<br /> <br /> This helper should be deprecated, given prevalence of TLS I doubt it has<br /> any relevance in 2026.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: bail out on template ct in get eval<br /> <br /> I noticed this issue while looking at a historic syzbot report [1].<br /> <br /> A rule like the one below is enough to trigger the bug:<br /> <br /> table ip t {<br /> chain pre {<br /> type filter hook prerouting priority raw;<br /> ct zone set 1<br /> ct original saddr 1.2.3.4 accept<br /> }<br /> }<br /> <br /> The first expression attaches a per-cpu template ct via<br /> nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -&gt; kzalloc, tuple is all<br /> zero, nf_ct_l3num(ct) == 0). The next expression then calls<br /> nft_ct_get_eval() on the same skb, treats the template as a real ct<br /> and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this<br /> overflows past struct nft_regs on the kernel stack; with smaller<br /> dreg values it silently clobbers adjacent registers.<br /> <br /> Reject template ct at the eval entry and in nft_ct_get_fast_eval(),<br /> mirroring the check nft_ct_set_eval() already has. Additionally,<br /> bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv-&gt;len<br /> instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple<br /> before pkt_to_tuple() fills in only the protocol-relevant leading<br /> bytes, so the trailing bytes of tuple-&gt;{src,dst}.u3.all are<br /> well-defined zero. priv-&gt;len is validated at rule load, so the<br /> copy size is now bounded by the destination register rather than<br /> by an untrusted field on the conntrack.<br /> <br /> [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c