Vulnerabilities

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') 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 ('Cross-site Scripting') 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 ('SQL Injection') 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 /> 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 /> 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).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix implicit ODP hang on parent deregistration<br /> <br /> Fix the destroy_unused_implicit_child_mr() to prevent hanging during<br /> parent deregistration as of below [1].<br /> <br /> Upon entering destroy_unused_implicit_child_mr(), the reference count<br /> for the implicit MR parent is incremented using:<br /> refcount_inc_not_zero().<br /> <br /> A corresponding decrement must be performed if<br /> free_implicit_child_mr_work() is not called.<br /> <br /> The code has been updated to properly manage the reference count that<br /> was incremented.<br /> <br /> [1]<br /> INFO: task python3:2157 blocked for more than 120 seconds.<br /> Not tainted 6.12.0-rc7+ #1633<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000<br /> Call Trace:<br /> <br /> __schedule+0x420/0xd30<br /> schedule+0x47/0x130<br /> __mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]<br /> ? __pfx_autoremove_wake_function+0x10/0x10<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+0xc1/0x2f0<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]<br /> ? lock_release+0xc6/0x280<br /> ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> __x64_sys_ioctl+0x1b0/0xa70<br /> ? kmem_cache_free+0x221/0x400<br /> do_syscall_64+0x6b/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f20f21f017b<br /> RSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b<br /> RDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890<br /> R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix a WARN during dereg_mr for DM type<br /> <br /> Memory regions (MR) of type DM (device memory) do not have an associated<br /> umem.<br /> <br /> In the __mlx5_ib_dereg_mr() -&gt; mlx5_free_priv_descs() flow, the code<br /> incorrectly takes the wrong branch, attempting to call<br /> dma_unmap_single() on a DMA address that is not mapped.<br /> <br /> This results in a WARN [1], as shown below.<br /> <br /> The issue is resolved by properly accounting for the DM type and<br /> ensuring the correct branch is selected in mlx5_free_priv_descs().<br /> <br /> [1]<br /> WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90<br /> Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core<br /> CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommu_dma_unmap_page+0x79/0x90<br /> Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00<br /> RSP: 0018:ffffc90001913a10 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001<br /> RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn+0x84/0x190<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? report_bug+0xf8/0x1c0<br /> ? handle_bug+0x55/0x90<br /> ? exc_invalid_op+0x13/0x60<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> dma_unmap_page_attrs+0xe6/0x290<br /> mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]<br /> __mlx5_ib_dereg_mr+0x37e/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+0xc1/0x2f0<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]<br /> ? lock_release+0xc6/0x280<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:0x7f537adaf17b<br /> Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b<br /> RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270<br /> R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190<br /> R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450<br />

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 /> 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 /> net: better track kernel sockets lifetime<br /> <br /> While kernel sockets are dismantled during pernet_operations-&gt;exit(),<br /> their freeing can be delayed by any tx packets still held in qdisc<br /> or device queues, due to skb_set_owner_w() prior calls.<br /> <br /> This then trigger the following warning from ref_tracker_dir_exit() [1]<br /> <br /> To fix this, make sure that kernel sockets own a reference on net-&gt;passive.<br /> <br /> Add sk_net_refcnt_upgrade() helper, used whenever a kernel socket<br /> is converted to a refcounted one.<br /> <br /> [1]<br /> <br /> [ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at<br /> [ 136.263918][ T35] sk_alloc+0x2b3/0x370<br /> [ 136.263918][ T35] inet6_create+0x6ce/0x10f0<br /> [ 136.263918][ T35] __sock_create+0x4c0/0xa30<br /> [ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250<br /> [ 136.263918][ T35] igmp6_net_init+0x39/0x390<br /> [ 136.263918][ T35] ops_init+0x31e/0x590<br /> [ 136.263918][ T35] setup_net+0x287/0x9e0<br /> [ 136.263918][ T35] copy_net_ns+0x33f/0x570<br /> [ 136.263918][ T35] create_new_namespaces+0x425/0x7b0<br /> [ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180<br /> [ 136.263918][ T35] ksys_unshare+0x57d/0xa70<br /> [ 136.263918][ T35] __x64_sys_unshare+0x38/0x40<br /> [ 136.263918][ T35] do_syscall_64+0xf3/0x230<br /> [ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 136.263918][ T35]<br /> [ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at<br /> [ 136.343488][ T35] sk_alloc+0x2b3/0x370<br /> [ 136.343488][ T35] inet6_create+0x6ce/0x10f0<br /> [ 136.343488][ T35] __sock_create+0x4c0/0xa30<br /> [ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250<br /> [ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0<br /> [ 136.343488][ T35] ops_init+0x31e/0x590<br /> [ 136.343488][ T35] setup_net+0x287/0x9e0<br /> [ 136.343488][ T35] copy_net_ns+0x33f/0x570<br /> [ 136.343488][ T35] create_new_namespaces+0x425/0x7b0<br /> [ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180<br /> [ 136.343488][ T35] ksys_unshare+0x57d/0xa70<br /> [ 136.343488][ T35] __x64_sys_unshare+0x38/0x40<br /> [ 136.343488][ T35] do_syscall_64+0xf3/0x230<br /> [ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers<br /> <br /> While using nvme target with use_srq on, below kernel panic is noticed.<br /> <br /> [ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)<br /> [ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> ..<br /> [ 566.393799] <br /> [ 566.393807] ? __die_body+0x1a/0x60<br /> [ 566.393823] ? die+0x38/0x60<br /> [ 566.393835] ? do_trap+0xe4/0x110<br /> [ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393881] ? do_error_trap+0x7c/0x120<br /> [ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393911] ? exc_divide_error+0x34/0x50<br /> [ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393939] ? asm_exc_divide_error+0x16/0x20<br /> [ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re]<br /> [ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re]<br /> [ 566.394057] ? srso_return_thunk+0x5/0x5f<br /> [ 566.394068] ? __init_swait_queue_head+0x4a/0x60<br /> [ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core]<br /> [ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma]<br /> [ 566.394174] ? lock_release+0x22c/0x3f0<br /> [ 566.394187] ? srso_return_thunk+0x5/0x5f<br /> <br /> Page size and shift info is set only for the user space SRQs.<br /> Set page size and page shift for kernel space SRQs also.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Add RCU read lock protection to perf_iterate_ctx()<br /> <br /> The perf_iterate_ctx() function performs RCU list traversal but<br /> currently lacks RCU read lock protection. This causes lockdep warnings<br /> when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:<br /> <br /> WARNING: suspicious RCU usage<br /> kernel/events/core.c:8168 RCU-list traversed in non-reader section!!<br /> <br /> Call Trace:<br /> lockdep_rcu_suspicious<br /> ? perf_event_addr_filters_apply<br /> perf_iterate_ctx<br /> perf_event_exec<br /> begin_new_exec<br /> ? load_elf_phdrs<br /> load_elf_binary<br /> ? lock_acquire<br /> ? find_held_lock<br /> ? bprm_execve<br /> bprm_execve<br /> do_execveat_common.isra.0<br /> __x64_sys_execve<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> This protection was previously present but was removed in commit<br /> bd2756811766 ("perf: Rewrite core context handling"). Add back the<br /> necessary rcu_read_lock()/rcu_read_unlock() pair around<br /> perf_iterate_ctx() call in perf_event_exec().<br /> <br /> [ mingo: Use scoped_guard() as suggested by Peter ]