Vulnerabilities

The SiteOrigin Widgets Bundle plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'siteorigin_widget' shortcode in all versions up to, and including, 1.60.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The WPB Elementor Addons plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in all versions up to, and including, 1.0.9 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm, thp: bail out early in collapse_file for writeback page<br /> <br /> Currently collapse_file does not explicitly check PG_writeback, instead,<br /> page_has_private and try_to_release_page are used to filter writeback<br /> pages. This does not work for xfs with blocksize equal to or larger<br /> than pagesize, because in such case xfs has no page-&gt;private.<br /> <br /> This makes collapse_file bail out early for writeback page. Otherwise,<br /> xfs end_page_writeback will panic as follows.<br /> <br /> page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:ffff0003f88c86a8 index:0x0 pfn:0x84ef32<br /> aops:xfs_address_space_operations [xfs] ino:30000b7 dentry name:"libtest.so"<br /> flags: 0x57fffe0000008027(locked|referenced|uptodate|active|writeback)<br /> raw: 57fffe0000008027 ffff80001b48bc28 ffff80001b48bc28 ffff0003f88c86a8<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff ffff0000c3e9a000<br /> page dumped because: VM_BUG_ON_PAGE(((unsigned int) page_ref_count(page) + 127u mem_cgroup:ffff0000c3e9a000<br /> ------------[ cut here ]------------<br /> kernel BUG at include/linux/mm.h:1212!<br /> Internal error: Oops - BUG: 0 [#1] SMP<br /> Modules linked in:<br /> BUG: Bad page state in process khugepaged pfn:84ef32<br /> xfs(E)<br /> page:fffffe00201bcc80 refcount:0 mapcount:0 mapping:0 index:0x0 pfn:0x84ef32<br /> libcrc32c(E) rfkill(E) aes_ce_blk(E) crypto_simd(E) ...<br /> CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Tainted: ...<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> Call trace:<br /> end_page_writeback+0x1c0/0x214<br /> iomap_finish_page_writeback+0x13c/0x204<br /> iomap_finish_ioend+0xe8/0x19c<br /> iomap_writepage_end_bio+0x38/0x50<br /> bio_endio+0x168/0x1ec<br /> blk_update_request+0x278/0x3f0<br /> blk_mq_end_request+0x34/0x15c<br /> virtblk_request_done+0x38/0x74 [virtio_blk]<br /> blk_done_softirq+0xc4/0x110<br /> __do_softirq+0x128/0x38c<br /> __irq_exit_rcu+0x118/0x150<br /> irq_exit+0x1c/0x30<br /> __handle_domain_irq+0x8c/0xf0<br /> gic_handle_irq+0x84/0x108<br /> el1_irq+0xcc/0x180<br /> arch_cpu_idle+0x18/0x40<br /> default_idle_call+0x4c/0x1a0<br /> cpuidle_idle_call+0x168/0x1e0<br /> do_idle+0xb4/0x104<br /> cpu_startup_entry+0x30/0x9c<br /> secondary_start_kernel+0x104/0x180<br /> Code: d4210000 b0006161 910c8021 94013f4d (d4210000)<br /> ---[ end trace 4a88c6a074082f8c ]---<br /> Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix race between searching chunks and release journal_head from buffer_head<br /> <br /> Encountered a race between ocfs2_test_bg_bit_allocatable() and<br /> jbd2_journal_put_journal_head() resulting in the below vmcore.<br /> <br /> PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3"<br /> Call trace:<br /> panic<br /> oops_end<br /> no_context<br /> __bad_area_nosemaphore<br /> bad_area_nosemaphore<br /> __do_page_fault<br /> do_page_fault<br /> page_fault<br /> [exception RIP: ocfs2_block_group_find_clear_bits+316]<br /> ocfs2_block_group_find_clear_bits [ocfs2]<br /> ocfs2_cluster_group_search [ocfs2]<br /> ocfs2_search_chain [ocfs2]<br /> ocfs2_claim_suballoc_bits [ocfs2]<br /> __ocfs2_claim_clusters [ocfs2]<br /> ocfs2_claim_clusters [ocfs2]<br /> ocfs2_local_alloc_slide_window [ocfs2]<br /> ocfs2_reserve_local_alloc_bits [ocfs2]<br /> ocfs2_reserve_clusters_with_limit [ocfs2]<br /> ocfs2_reserve_clusters [ocfs2]<br /> ocfs2_lock_refcount_allocators [ocfs2]<br /> ocfs2_make_clusters_writable [ocfs2]<br /> ocfs2_replace_cow [ocfs2]<br /> ocfs2_refcount_cow [ocfs2]<br /> ocfs2_file_write_iter [ocfs2]<br /> lo_rw_aio<br /> loop_queue_work<br /> kthread_worker_fn<br /> kthread<br /> ret_from_fork<br /> <br /> When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the<br /> bg_bh-&gt;b_private NULL as jbd2_journal_put_journal_head() raced and<br /> released the jounal head from the buffer head. Needed to take bit lock<br /> for the bit &amp;#39;BH_JournalHead&amp;#39; to fix this race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfg80211: fix management registrations locking<br /> <br /> The management registrations locking was broken, the list was<br /> locked for each wdev, but cfg80211_mgmt_registrations_update()<br /> iterated it without holding all the correct spinlocks, causing<br /> list corruption.<br /> <br /> Rather than trying to fix it with fine-grained locking, just<br /> move the lock to the wiphy/rdev (still need the list on each<br /> wdev), we already need to hold the wdev lock to change it, so<br /> there&amp;#39;s no contention on the lock in any case. This trivially<br /> fixes the bug since we hold one wdev&amp;#39;s lock already, and now<br /> will hold the lock that protects all lists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: sanity check for maxpacket<br /> <br /> maxpacket of 0 makes no sense and oopses as we need to divide<br /> by it. Give up.<br /> <br /> V2: fixed typo in log and stylistic issues

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: Fix flipped sign in tls_err_abort() calls<br /> <br /> sk-&gt;sk_err appears to expect a positive value, a convention that ktls<br /> doesn&amp;#39;t always follow and that leads to memory corruption in other code.<br /> For instance,<br /> <br /> [kworker]<br /> tls_encrypt_done(..., err=)<br /> tls_err_abort(.., err)<br /> sk-&gt;sk_err = err;<br /> <br /> [task]<br /> splice_from_pipe_feed<br /> ...<br /> tls_sw_do_sendpage<br /> if (sk-&gt;sk_err) {<br /> ret = -sk-&gt;sk_err; // ret is positive<br /> <br /> splice_from_pipe_feed (continued)<br /> ret = actor(...) // ret is still positive and interpreted as bytes<br /> // written, resulting in underflow of buf-&gt;len and<br /> // sd-&gt;len, leading to huge buf-&gt;offset and bogus<br /> // addresses computed in later calls to actor()<br /> <br /> Fix all tls_err_abort() callers to pass a negative error code<br /> consistently and centralize the error-prone sign flip there, throwing in<br /> a warning to catch future misuse and uninlining the function so it<br /> really does only warn once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells<br /> <br /> If a cell has &amp;#39;nbits&amp;#39; equal to a multiple of BITS_PER_BYTE the logic<br /> <br /> *p &amp;= GENMASK((cell-&gt;nbits%BITS_PER_BYTE) - 1, 0);<br /> <br /> will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we<br /> subtract one from that making a large number that is then shifted more than the<br /> number of bits that fit into an unsigned long.<br /> <br /> UBSAN reports this problem:<br /> <br /> UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8<br /> shift exponent 64 is too large for 64-bit type &amp;#39;unsigned long&amp;#39;<br /> CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9<br /> Hardware name: Google Lazor (rev3+) with KB Backlight (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x0/0x170<br /> show_stack+0x24/0x30<br /> dump_stack_lvl+0x64/0x7c<br /> dump_stack+0x18/0x38<br /> ubsan_epilogue+0x10/0x54<br /> __ubsan_handle_shift_out_of_bounds+0x180/0x194<br /> __nvmem_cell_read+0x1ec/0x21c<br /> nvmem_cell_read+0x58/0x94<br /> nvmem_cell_read_variable_common+0x4c/0xb0<br /> nvmem_cell_read_variable_le_u32+0x40/0x100<br /> a6xx_gpu_init+0x170/0x2f4<br /> adreno_bind+0x174/0x284<br /> component_bind_all+0xf0/0x264<br /> msm_drm_bind+0x1d8/0x7a0<br /> try_to_bring_up_master+0x164/0x1ac<br /> __component_add+0xbc/0x13c<br /> component_add+0x20/0x2c<br /> dp_display_probe+0x340/0x384<br /> platform_probe+0xc0/0x100<br /> really_probe+0x110/0x304<br /> __driver_probe_device+0xb8/0x120<br /> driver_probe_device+0x4c/0xfc<br /> __device_attach_driver+0xb0/0x128<br /> bus_for_each_drv+0x90/0xdc<br /> __device_attach+0xc8/0x174<br /> device_initial_probe+0x20/0x2c<br /> bus_probe_device+0x40/0xa4<br /> deferred_probe_work_func+0x7c/0xb8<br /> process_one_work+0x128/0x21c<br /> process_scheduled_works+0x40/0x54<br /> worker_thread+0x1ec/0x2a8<br /> kthread+0x138/0x158<br /> ret_from_fork+0x10/0x20<br /> <br /> Fix it by making sure there are any bits to mask out.

The ApplyOnline – Application Form Builder and Manager plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the aol_modal_box AJAX action in all versions up to, and including, 2.6. This makes it possible for authenticated attackers, with subscriber access or higher, to view Application submissions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm rq: don&amp;#39;t queue request to blk-mq during DM suspend<br /> <br /> DM uses blk-mq&amp;#39;s quiesce/unquiesce to stop/start device mapper queue.<br /> <br /> But blk-mq&amp;#39;s unquiesce may come from outside events, such as elevator<br /> switch, updating nr_requests or others, and request may come during<br /> suspend, so simply ask for blk-mq to requeue it.<br /> <br /> Fixes one kernel panic issue when running updating nr_requests and<br /> dm-mpath suspend/resume stress test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Initialize the ODP xarray when creating an ODP MR<br /> <br /> Normally the zero fill would hide the missing initialization, but an<br /> errant set to desc_size in reg_create() causes a crash:<br /> <br /> BUG: unable to handle page fault for address: 0000000800000000<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 5 PID: 890 Comm: ib_write_bw Not tainted 5.15.0-rc4+ #47<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:mlx5_ib_dereg_mr+0x14/0x3b0 [mlx5_ib]<br /> Code: 48 63 cd 4c 89 f7 48 89 0c 24 e8 37 30 03 e1 48 8b 0c 24 eb a0 90 0f 1f 44 00 00 41 56 41 55 41 54 55 53 48 89 fb 48 83 ec 30 8b 2f 65 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 8b 87 c8<br /> RSP: 0018:ffff88811afa3a60 EFLAGS: 00010286<br /> RAX: 000000000000001c RBX: 0000000800000000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000800000000<br /> RBP: 0000000800000000 R08: 0000000000000000 R09: c0000000fffff7ff<br /> R10: ffff88811afa38f8 R11: ffff88811afa38f0 R12: ffffffffa02c7ac0<br /> R13: 0000000000000000 R14: ffff88811afa3cd8 R15: ffff88810772fa00<br /> FS: 00007f47b9080740(0000) GS:ffff88852cd40000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000800000000 CR3: 000000010761e003 CR4: 0000000000370ea0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> mlx5_ib_free_odp_mr+0x95/0xc0 [mlx5_ib]<br /> mlx5_ib_dereg_mr+0x128/0x3b0 [mlx5_ib]<br /> ib_dereg_mr_user+0x45/0xb0 [ib_core]<br /> ? xas_load+0x8/0x80<br /> destroy_hw_idr_uobject+0x1a/0x50 [ib_uverbs]<br /> uverbs_destroy_uobject+0x2f/0x150 [ib_uverbs]<br /> uobj_destroy+0x3c/0x70 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x467/0xb00 [ib_uverbs]<br /> ? uverbs_finalize_object+0x60/0x60 [ib_uverbs]<br /> ? ttwu_queue_wakelist+0xa9/0xe0<br /> ? pty_write+0x85/0x90<br /> ? file_tty_write.isra.33+0x214/0x330<br /> ? process_echoes+0x60/0x60<br /> ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs]<br /> __x64_sys_ioctl+0x10d/0x8e0<br /> ? vfs_write+0x17f/0x260<br /> do_syscall_64+0x3c/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Add the missing xarray initialization and remove the desc_size set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: batman-adv: fix error handling<br /> <br /> Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was<br /> in wrong error handling in batadv_mesh_init().<br /> <br /> Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case<br /> of any batadv_*_init() calls failure. This approach may work well, when<br /> there is some kind of indicator, which can tell which parts of batadv are<br /> initialized; but there isn&amp;#39;t any.<br /> <br /> All written above lead to cleaning up uninitialized fields. Even if we hide<br /> ODEBUG warning by initializing bat_priv-&gt;nc.work, syzbot was able to hit<br /> GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]<br /> <br /> To fix these bugs we can unwind batadv_*_init() calls one by one.<br /> It is good approach for 2 reasons: 1) It fixes bugs on error handling<br /> path 2) It improves the performance, since we won&amp;#39;t call unneeded<br /> batadv_*_free() functions.<br /> <br /> So, this patch makes all batadv_*_init() clean up all allocated memory<br /> before returning with an error to no call correspoing batadv_*_free()<br /> and open-codes batadv_mesh_free() with proper order to avoid touching<br /> uninitialized fields.