Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: ensure network headers are in skb linear part<br /> <br /> syzbot found that ipvlan_process_v6_outbound() was assuming<br /> the IPv6 network header isis present in skb-&gt;head [1]<br /> <br /> Add the needed pskb_network_may_pull() calls for both<br /> IPv4 and IPv6 handlers.<br /> <br /> [1]<br /> BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47<br /> __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47<br /> ipv6_addr_type include/net/ipv6.h:555 [inline]<br /> ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline]<br /> ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651<br /> ip6_route_output include/net/ip6_route.h:93 [inline]<br /> ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476<br /> ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline]<br /> ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline]<br /> ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline]<br /> ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671<br /> ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223<br /> __netdev_start_xmit include/linux/netdevice.h:5150 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5159 [inline]<br /> xmit_one net/core/dev.c:3735 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751<br /> sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343<br /> qdisc_restart net/sched/sch_generic.c:408 [inline]<br /> __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416<br /> qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127<br /> net_tx_action+0x78b/0x940 net/core/dev.c:5484<br /> handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561<br /> __do_softirq+0x14/0x1a kernel/softirq.c:595<br /> do_softirq+0x9a/0x100 kernel/softirq.c:462<br /> __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]<br /> __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611<br /> dev_queue_xmit include/linux/netdevice.h:3311 [inline]<br /> packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3132 [inline]<br /> packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164<br /> sock_sendmsg_nosec net/socket.c:718 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix the recovery flow of the UMR QP<br /> <br /> This patch addresses an issue in the recovery flow of the UMR QP,<br /> ensuring tasks do not get stuck, as highlighted by the call trace [1].<br /> <br /> During recovery, before transitioning the QP to the RESET state, the<br /> software must wait for all outstanding WRs to complete.<br /> <br /> Failing to do so can cause the firmware to skip sending some flushed<br /> CQEs with errors and simply discard them upon the RESET, as per the IB<br /> specification.<br /> <br /> This race condition can result in lost CQEs and tasks becoming stuck.<br /> <br /> To resolve this, the patch sends a final WR which serves only as a<br /> barrier before moving the QP state to RESET.<br /> <br /> Once a CQE is received for that final WR, it guarantees that no<br /> outstanding WRs remain, making it safe to transition the QP to RESET and<br /> subsequently back to RTS, restoring proper functionality.<br /> <br /> Note:<br /> For the barrier WR, we simply reuse the failed and ready WR.<br /> Since the QP is in an error state, it will only receive<br /> IB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don&amp;#39;t<br /> care about its status.<br /> <br /> [1]<br /> INFO: task rdma_resource_l:1922 blocked for more than 120 seconds.<br /> Tainted: G W 6.12.0-rc7+ #1626<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:rdma_resource_l state:D stack:0 pid:1922 tgid:1922 ppid:1369<br /> flags:0x00004004<br /> Call Trace:<br /> <br /> __schedule+0x420/0xd30<br /> schedule+0x47/0x130<br /> schedule_timeout+0x280/0x300<br /> ? mark_held_locks+0x48/0x80<br /> ? lockdep_hardirqs_on_prepare+0xe5/0x1a0<br /> wait_for_completion+0x75/0x130<br /> mlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib]<br /> ? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib]<br /> mlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib]<br /> __mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib]<br /> ? _raw_spin_unlock_irq+0x24/0x40<br /> ? wait_for_completion+0xfe/0x130<br /> ? rdma_restrack_put+0x63/0xe0 [ib_core]<br /> ib_dereg_mr_user+0x5f/0x120 [ib_core]<br /> ? lock_release+0xc6/0x280<br /> destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]<br /> uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]<br /> uobj_destroy+0x3f/0x70 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]<br /> ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]<br /> ? __lock_acquire+0x64e/0x2080<br /> ? mark_held_locks+0x48/0x80<br /> ? find_held_lock+0x2d/0xa0<br /> ? lock_acquire+0xc1/0x2f0<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> ? __fget_files+0xc3/0x1b0<br /> ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> __x64_sys_ioctl+0x1b0/0xa70<br /> do_syscall_64+0x6b/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f99c918b17b<br /> RSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX:<br /> 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX:<br /> 00007f99c918b17b<br /> RDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI:<br /> 0000000000000003<br /> RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09:<br /> 000000000000bd7e<br /> R10: 00007f99c94c1c70 R11: 0000000000000246 R12:<br /> 00007ffc766d0530<br /> R13: 000000000000001c R14: 0000000040246a80 R15:<br /> 0000000000000000<br />

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in ThemeHunk Vayu Blocks – Gutenberg Blocks for WordPress &amp; WooCommerce vayu-blocks allows Stored XSS.This issue affects Vayu Blocks – Gutenberg Blocks for WordPress &amp; WooCommerce: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Syed Balkhi aThemes Addons for Elementor athemes-addons-for-elementor-lite allows Stored XSS.This issue affects aThemes Addons for Elementor: from n/a through

Missing Authorization vulnerability in Smackcoders Inc., AIO Performance Profiler, Monitor, Optimize, Compress &amp; Debug all-in-one-performance-accelerator allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects AIO Performance Profiler, Monitor, Optimize, Compress &amp; Debug: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Plugin Devs Blog, Posts and Category Filter for Elementor blog-posts-and-category-for-elementor allows Stored XSS.This issue affects Blog, Posts and Category Filter for Elementor: from n/a through

Improper Neutralization of Input During Web Page Generation (&amp;#39;Cross-site Scripting&amp;#39;) vulnerability in weDevs WP Project Manager wedevs-project-manager allows Stored XSS.This issue affects WP Project Manager: from n/a through

Improper Neutralization of Special Elements used in an SQL Command (&amp;#39;SQL Injection&amp;#39;) vulnerability in kendysond Payment Forms for Paystack payment-forms-for-paystack allows SQL Injection.This issue affects Payment Forms for Paystack: from n/a through

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up<br /> <br /> The issue was caused by dput(upper) being called before<br /> ovl_dentry_update_reval(), while upper-&gt;d_flags was still<br /> accessed in ovl_dentry_remote().<br /> <br /> Move dput(upper) after its last use to prevent use-after-free.<br /> <br /> BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline]<br /> BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167<br /> <br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0xc3/0x620 mm/kasan/report.c:488<br /> kasan_report+0xd9/0x110 mm/kasan/report.c:601<br /> ovl_dentry_remote fs/overlayfs/util.c:162 [inline]<br /> ovl_dentry_update_reval+0xd2/0xf0 fs/overlayfs/util.c:167<br /> ovl_link_up fs/overlayfs/copy_up.c:610 [inline]<br /> ovl_copy_up_one+0x2105/0x3490 fs/overlayfs/copy_up.c:1170<br /> ovl_copy_up_flags+0x18d/0x200 fs/overlayfs/copy_up.c:1223<br /> ovl_rename+0x39e/0x18c0 fs/overlayfs/dir.c:1136<br /> vfs_rename+0xf84/0x20a0 fs/namei.c:4893<br /> ...<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes: Reject the shared zeropage in uprobe_write_opcode()<br /> <br /> We triggered the following crash in syzkaller tests:<br /> <br /> BUG: Bad page state in process syz.7.38 pfn:1eff3<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3<br /> flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff)<br /> raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000<br /> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x32/0x50<br /> bad_page+0x69/0xf0<br /> free_unref_page_prepare+0x401/0x500<br /> free_unref_page+0x6d/0x1b0<br /> uprobe_write_opcode+0x460/0x8e0<br /> install_breakpoint.part.0+0x51/0x80<br /> register_for_each_vma+0x1d9/0x2b0<br /> __uprobe_register+0x245/0x300<br /> bpf_uprobe_multi_link_attach+0x29b/0x4f0<br /> link_create+0x1e2/0x280<br /> __sys_bpf+0x75f/0xac0<br /> __x64_sys_bpf+0x1a/0x30<br /> do_syscall_64+0x56/0x100<br /> entry_SYSCALL_64_after_hwframe+0x78/0xe2<br /> <br /> BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1<br /> <br /> The following syzkaller test case can be used to reproduce:<br /> <br /> r2 = creat(&amp;(0x7f0000000000)=&amp;#39;./file0\x00&amp;#39;, 0x8)<br /> write$nbd(r2, &amp;(0x7f0000000580)=ANY=[], 0x10)<br /> r4 = openat(0xffffffffffffff9c, &amp;(0x7f0000000040)=&amp;#39;./file0\x00&amp;#39;, 0x42, 0x0)<br /> mmap$IORING_OFF_SQ_RING(&amp;(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0)<br /> r5 = userfaultfd(0x80801)<br /> ioctl$UFFDIO_API(r5, 0xc018aa3f, &amp;(0x7f0000000040)={0xaa, 0x20})<br /> r6 = userfaultfd(0x80801)<br /> ioctl$UFFDIO_API(r6, 0xc018aa3f, &amp;(0x7f0000000140))<br /> ioctl$UFFDIO_REGISTER(r6, 0xc020aa00, &amp;(0x7f0000000100)={{&amp;(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2})<br /> ioctl$UFFDIO_ZEROPAGE(r5, 0xc020aa04, &amp;(0x7f0000000000)={{&amp;(0x7f0000ffd000/0x1000)=nil, 0x1000}})<br /> r7 = bpf$PROG_LOAD(0x5, &amp;(0x7f0000000140)={0x2, 0x3, &amp;(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &amp;(0x7f0000000000)=&amp;#39;GPL\x00&amp;#39;, 0x7, 0x0, 0x0, 0x0, 0x0, &amp;#39;\x00&amp;#39;, 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94)<br /> bpf$BPF_LINK_CREATE_XDP(0x1c, &amp;(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobe_multi={&amp;(0x7f0000000080)=&amp;#39;./file0\x00&amp;#39;, &amp;(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)<br /> <br /> The cause is that zero pfn is set to the PTE without increasing the RSS<br /> count in mfill_atomic_pte_zeropage() and the refcount of zero folio does<br /> not increase accordingly. Then, the operation on the same pfn is performed<br /> in uprobe_write_opcode()-&gt;__replace_page() to unconditional decrease the<br /> RSS count and old_folio&amp;#39;s refcount.<br /> <br /> Therefore, two bugs are introduced:<br /> <br /> 1. The RSS count is incorrect, when process exit, the check_mm() report<br /> error "Bad rss-count".<br /> <br /> 2. The reserved folio (zero folio) is freed when folio-&gt;refcount is zero,<br /> then free_pages_prepare-&gt;free_page_is_bad() report error<br /> "Bad page state".<br /> <br /> There is more, the following warning could also theoretically be triggered:<br /> <br /> __replace_page()<br /> -&gt; ...<br /> -&gt; folio_remove_rmap_pte()<br /> -&gt; VM_WARN_ON_FOLIO(is_zero_folio(folio), folio)<br /> <br /> Considering that uprobe hit on the zero folio is a very rare case, just<br /> reject zero old folio immediately after get_user_page_vma_remote().<br /> <br /> [ mingo: Cleaned up the changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix vport QoS cleanup on error<br /> <br /> When enabling vport QoS fails, the scheduling node was never freed,<br /> causing a leak.<br /> <br /> Add the missing free and reset the vport scheduling node pointer to<br /> NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix deinitializing VF in error path<br /> <br /> If ice_ena_vfs() fails after calling ice_create_vf_entries(), it frees<br /> all VFs without removing them from snapshot PF-VF mailbox list, leading<br /> to list corruption.<br /> <br /> Reproducer:<br /> devlink dev eswitch set $PF1_PCI mode switchdev<br /> ip l s $PF1 up<br /> ip l s $PF1 promisc on<br /> sleep 1<br /> echo 1 &gt; /sys/class/net/$PF1/device/sriov_numvfs<br /> sleep 1<br /> echo 1 &gt; /sys/class/net/$PF1/device/sriov_numvfs<br /> <br /> Trace (minimized):<br /> list_add corruption. next-&gt;prev should be prev (ffff8882e241c6f0), but was 0000000000000000. (next=ffff888455da1330).<br /> kernel BUG at lib/list_debug.c:29!<br /> RIP: 0010:__list_add_valid_or_report+0xa6/0x100<br /> ice_mbx_init_vf_info+0xa7/0x180 [ice]<br /> ice_initialize_vf_entry+0x1fa/0x250 [ice]<br /> ice_sriov_configure+0x8d7/0x1520 [ice]<br /> ? __percpu_ref_switch_mode+0x1b1/0x5d0<br /> ? __pfx_ice_sriov_configure+0x10/0x10 [ice]<br /> <br /> Sometimes a KASAN report can be seen instead with a similar stack trace:<br /> BUG: KASAN: use-after-free in __list_add_valid_or_report+0xf1/0x100<br /> <br /> VFs are added to this list in ice_mbx_init_vf_info(), but only removed<br /> in ice_free_vfs(). Move the removing to ice_free_vf_entries(), which is<br /> also being called in other places where VFs are being removed (including<br /> ice_free_vfs() itself).