Vulnerabilities

The Gestpay for WooCommerce plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 20221130. This is due to missing or incorrect nonce validation on the 'ajax_unset_default_card' function. This makes it possible for unauthenticated attackers to remove the default status of a card token for a user via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

The WP Private Content Plus plugin for WordPress is vulnerable to information disclosure in all versions up to, and including, 3.6. This is due to the plugin not properly restricting access to posts via the REST API when a page has been made private. This makes it possible for unauthenticated attackers to view protected posts.

The Page Restrict plugin for WordPress is vulnerable to information disclosure in all versions up to, and including, 2.5.5. This is due to the plugin not properly restricting access to posts via the REST API when a page has been made private. This makes it possible for unauthenticated attackers to view protected posts.

The Envo's Elementor Templates & Widgets for WooCommerce plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the templates_ajax_request function in all versions up to, and including, 1.4.4. This makes it possible for subscribers and higher to create templates.

The Envo's Elementor Templates & Widgets for WooCommerce plugin for WordPress is vulnerable to Cross-Site Request Forgery in versions up to, and including, 1.4.4. This is due to missing or incorrect nonce validation on the ajax_plugin_activation function. This makes it possible for unauthenticated attackers to activate arbitrary installed plugins via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: fix incorrect locking in state_change sk callback<br /> <br /> We are not changing anything in the TCP connection state so<br /> we should not take a write_lock but rather a read lock.<br /> <br /> This caused a deadlock when running nvmet-tcp and nvme-tcp<br /> on the same system, where state_change callbacks on the<br /> host and on the controller side have causal relationship<br /> and made lockdep report on this with blktests:<br /> <br /> ================================<br /> WARNING: inconsistent lock state<br /> 5.12.0-rc3 #1 Tainted: G I<br /> --------------------------------<br /> inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-R} usage.<br /> nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp]<br /> {IN-SOFTIRQ-W} state was registered at:<br /> __lock_acquire+0x79b/0x18d0<br /> lock_acquire+0x1ca/0x480<br /> _raw_write_lock_bh+0x39/0x80<br /> nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp]<br /> tcp_fin+0x2a8/0x780<br /> tcp_data_queue+0xf94/0x1f20<br /> tcp_rcv_established+0x6ba/0x1f00<br /> tcp_v4_do_rcv+0x502/0x760<br /> tcp_v4_rcv+0x257e/0x3430<br /> ip_protocol_deliver_rcu+0x69/0x6a0<br /> ip_local_deliver_finish+0x1e2/0x2f0<br /> ip_local_deliver+0x1a2/0x420<br /> ip_rcv+0x4fb/0x6b0<br /> __netif_receive_skb_one_core+0x162/0x1b0<br /> process_backlog+0x1ff/0x770<br /> __napi_poll.constprop.0+0xa9/0x5c0<br /> net_rx_action+0x7b3/0xb30<br /> __do_softirq+0x1f0/0x940<br /> do_softirq+0xa1/0xd0<br /> __local_bh_enable_ip+0xd8/0x100<br /> ip_finish_output2+0x6b7/0x18a0<br /> __ip_queue_xmit+0x706/0x1aa0<br /> __tcp_transmit_skb+0x2068/0x2e20<br /> tcp_write_xmit+0xc9e/0x2bb0<br /> __tcp_push_pending_frames+0x92/0x310<br /> inet_shutdown+0x158/0x300<br /> __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp]<br /> nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp]<br /> nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp]<br /> nvme_do_delete_ctrl+0x100/0x10c [nvme_core]<br /> nvme_sysfs_delete.cold+0x8/0xd [nvme_core]<br /> kernfs_fop_write_iter+0x2c7/0x460<br /> new_sync_write+0x36c/0x610<br /> vfs_write+0x5c0/0x870<br /> ksys_write+0xf9/0x1d0<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> irq event stamp: 10687<br /> hardirqs last enabled at (10687): [] _raw_spin_unlock_irqrestore+0x2d/0x40<br /> hardirqs last disabled at (10686): [] _raw_spin_lock_irqsave+0x68/0x90<br /> softirqs last enabled at (10684): [] __do_softirq+0x608/0x940<br /> softirqs last disabled at (10649): [] do_softirq+0xa1/0xd0<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(clock-AF_INET);<br /> <br /> lock(clock-AF_INET);<br /> <br /> *** DEADLOCK ***<br /> <br /> 5 locks held by nvme/1324:<br /> #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0<br /> #1: ffff8886e435c090 (&amp;of-&gt;mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460<br /> #2: ffff888104d90c38 (kn-&gt;active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330<br /> #3: ffff8884634538d0 (&amp;queue-&gt;queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp]<br /> #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300<br /> <br /> stack backtrace:<br /> CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1<br /> Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020<br /> Call Trace:<br /> dump_stack+0x93/0xc2<br /> mark_lock_irq.cold+0x2c/0xb3<br /> ? verify_lock_unused+0x390/0x390<br /> ? stack_trace_consume_entry+0x160/0x160<br /> ? lock_downgrade+0x100/0x100<br /> ? save_trace+0x88/0x5e0<br /> ? _raw_spin_unlock_irqrestore+0x2d/0x40<br /> mark_lock+0x530/0x1470<br /> ? mark_lock_irq+0x1d10/0x1d10<br /> ? enqueue_timer+0x660/0x660<br /> mark_usage+0x215/0x2a0<br /> __lock_acquire+0x79b/0x18d0<br /> ? tcp_schedule_loss_probe.part.0+0x38c/0x520<br /> lock_acquire+0x1ca/0x480<br /> ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]<br /> ? rcu_read_unlock+0x40/0x40<br /> ? tcp_mtu_probe+0x1ae0/0x1ae0<br /> ? kmalloc_reserve+0xa0/0xa0<br /> ? sysfs_file_ops+0x170/0x170<br /> _raw_read_lock+0x3d/0xa0<br /> ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp]<br /> nvme_tcp_state_change+0x21/0x150 [nvme_tcp]<br /> ? sysfs_file_ops<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Free local data after use<br /> <br /> Fixes the following memory leak in dc_link_construct():<br /> <br /> unreferenced object 0xffffa03e81471400 (size 1024):<br /> comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmem_cache_alloc_trace+0x30a/0x4a0<br /> [] link_create+0xce/0xac0 [amdgpu]<br /> [] dc_create+0x370/0x720 [amdgpu]<br /> [] amdgpu_dm_init+0x18e/0x17a0 [amdgpu]<br /> [] dm_hw_init+0x12/0x20 [amdgpu]<br /> [] amdgpu_device_init+0x1463/0x1e60 [amdgpu]<br /> [] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu]<br /> [] amdgpu_pci_probe+0x192/0x280 [amdgpu]<br /> [] local_pci_probe+0x47/0xa0<br /> [] pci_device_probe+0xe3/0x180<br /> [] really_probe+0x1c4/0x4e0<br /> [] driver_probe_device+0x62/0x150<br /> [] device_driver_attach+0x58/0x60<br /> [] __driver_attach+0xd6/0x150<br /> [] bus_for_each_dev+0x6a/0xc0<br /> [] driver_attach+0x1e/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: core: Fix some resource leaks in the error path of &amp;#39;venus_probe()&amp;#39;<br /> <br /> If an error occurs after a successful &amp;#39;of_icc_get()&amp;#39; call, it must be<br /> undone.<br /> <br /> Use &amp;#39;devm_of_icc_get()&amp;#39; instead of &amp;#39;of_icc_get()&amp;#39; to avoid the leak.<br /> Update the remove function accordingly and axe the now unneeded<br /> &amp;#39;icc_put()&amp;#39; calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix shift-out-of-bounds in load_balance()<br /> <br /> Syzbot reported a handful of occurrences where an sd-&gt;nr_balance_failed can<br /> grow to much higher values than one would expect.<br /> <br /> A successful load_balance() resets it to 0; a failed one increments<br /> it. Once it gets to sd-&gt;cache_nice_tries + 3, this *should* trigger an<br /> active balance, which will either set it to sd-&gt;cache_nice_tries+1 or reset<br /> it to 0. However, in case the to-be-active-balanced task is not allowed to<br /> run on env-&gt;dst_cpu, then the increment is done without any further<br /> modification.<br /> <br /> This could then be repeated ad nauseam, and would explain the absurdly high<br /> values reported by syzbot (86, 149). VincentG noted there is value in<br /> letting sd-&gt;cache_nice_tries grow, so the shift itself should be<br /> fixed. That means preventing:<br /> <br /> """<br /> If the value of the right operand is negative or is greater than or equal<br /> to the width of the promoted left operand, the behavior is undefined.<br /> """<br /> <br /> Thus we need to cap the shift exponent to<br /> BITS_PER_TYPE(typeof(lefthand)) - 1.<br /> <br /> I had a look around for other similar cases via coccinelle:<br /> <br /> @expr@<br /> position pos;<br /> expression E1;<br /> expression E2;<br /> @@<br /> (<br /> E1 &gt;&gt; E2@pos<br /> |<br /> E1 &gt;&gt; E2@pos<br /> )<br /> <br /> @cst depends on expr@<br /> position pos;<br /> expression expr.E1;<br /> constant cst;<br /> @@<br /> (<br /> E1 &gt;&gt; cst@pos<br /> |<br /> E1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()<br /> <br /> It is possible to call lpfc_issue_els_plogi() passing a did for which no<br /> matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a<br /> null pointer to a lpfc_nodelist structure resulting in a null pointer<br /> dereference.<br /> <br /> Fix by returning an error status if no valid ndlp is found. Fix up comments<br /> regarding ndlp reference counting.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix off by one in hdmi_14_process_transaction()<br /> <br /> The hdcp_i2c_offsets[] array did not have an entry for<br /> HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one<br /> read overflow. I added an entry and copied the 0x0 value for the offset<br /> from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c.<br /> <br /> I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX<br /> entries. This doesn&amp;#39;t change the code, but it&amp;#39;s just a belt and<br /> suspenders approach to try future proof the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails<br /> <br /> The spi controller supports 44-bit address space on AXI in DMA mode,<br /> so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping.<br /> In addition, if dma_map_single fails, it should return immediately<br /> instead of continuing doing the DMA operation which bases on invalid<br /> address.<br /> <br /> This fixes the following crash which occurs in reading a big block<br /> from flash:<br /> <br /> [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots)<br /> [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped<br /> [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0<br /> [ 123.792536] Mem abort info:<br /> [ 123.795313] ESR = 0x96000145<br /> [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 123.803655] SET = 0, FnV = 0<br /> [ 123.806693] EA = 0, S1PTW = 0<br /> [ 123.809818] Data abort info:<br /> [ 123.812683] ISV = 0, ISS = 0x00000145<br /> [ 123.816503] CM = 1, WnR = 1<br /> [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000<br /> [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000<br /> [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP