Vulnerabilities

The ARMember – Membership Plugin, Content Restriction, Member Levels, User Profile & User signup plugin for WordPress is vulnerable to Stored Cross-Site Scripting via SVG File uploads in all versions up to, and including, 4.0.37 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses the SVG file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix TTLM teardown work<br /> <br /> The worker calculates the wrong sdata pointer, so if it ever<br /> runs, it&amp;#39;ll crash. Fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove<br /> <br /> The following warning is seen during bwmon_remove due to refcount<br /> imbalance, fix this by releasing the OPPs after use.<br /> <br /> Logs:<br /> WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158<br /> Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT)<br /> ...<br /> Call trace:<br /> _opp_table_kref_release+0x150/0x158<br /> dev_pm_opp_remove_table+0x100/0x1b4<br /> devm_pm_opp_of_table_release+0x10/0x1c<br /> devm_action_release+0x14/0x20<br /> devres_release_all+0xa4/0x104<br /> device_unbind_cleanup+0x18/0x60<br /> device_release_driver_internal+0x1ec/0x228<br /> driver_detach+0x50/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> platform_driver_unregister+0x14/0x20<br /> bwmon_driver_exit+0x18/0x524 [icc_bwmon]<br /> __arm64_sys_delete_module+0x184/0x264<br /> invoke_syscall+0x48/0x118<br /> el0_svc_common.constprop.0+0xc8/0xe8<br /> do_el0_svc+0x20/0x2c<br /> el0_svc+0x34/0xdc<br /> el0t_64_sync_handler+0x13c/0x158<br /> el0t_64_sync+0x190/0x194<br /> --[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (ltc2991) re-order conditions to fix off by one bug<br /> <br /> LTC2991_T_INT_CH_NR is 4. The st-&gt;temp_en[] array has LTC2991_MAX_CHANNEL<br /> (4) elements. Thus if "channel" is equal to LTC2991_T_INT_CH_NR then we<br /> have read one element beyond the end of the array. Flip the conditions<br /> around so that we check if "channel" is valid before using it as an array<br /> index.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix null reference error when checking end of zone<br /> <br /> This patch fixes a potentially null pointer being accessed by<br /> is_end_zone_blkaddr() that checks the last block of a zone<br /> when f2fs is mounted as a single device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pdr: protect locator_addr with the main mutex<br /> <br /> If the service locator server is restarted fast enough, the PDR can<br /> rewrite locator_addr fields concurrently. Protect them by placing<br /> modification of those fields under the main pdr-&gt;lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: xilinx: rename cpu_number1 to dummy_cpu_number<br /> <br /> The per cpu variable cpu_number1 is passed to xlnx_event_handler as<br /> argument "dev_id", but it is not used in this function. So drop the<br /> initialization of this variable and rename it to dummy_cpu_number.<br /> This patch is to fix the following call trace when the kernel option<br /> CONFIG_DEBUG_ATOMIC_SLEEP is enabled:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 1, expected: 0<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53<br /> Hardware name: Xilinx Versal vmk180 Eval board rev1.1 (QSPI) (DT)<br /> Call trace:<br /> dump_backtrace+0xd0/0xe0<br /> show_stack+0x18/0x40<br /> dump_stack_lvl+0x7c/0xa0<br /> dump_stack+0x18/0x34<br /> __might_resched+0x10c/0x140<br /> __might_sleep+0x4c/0xa0<br /> __kmem_cache_alloc_node+0xf4/0x168<br /> kmalloc_trace+0x28/0x38<br /> __request_percpu_irq+0x74/0x138<br /> xlnx_event_manager_probe+0xf8/0x298<br /> platform_probe+0x68/0xd8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/cpuset: Prevent UAF in proc_cpuset_show()<br /> <br /> An UAF can happen when /proc/cpuset is read as reported in [1].<br /> <br /> This can be reproduced by the following methods:<br /> 1.add an mdelay(1000) before acquiring the cgroup_lock In the<br /> cgroup_path_ns function.<br /> 2.$cat /proc//cpuset repeatly.<br /> 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/<br /> $umount /sys/fs/cgroup/cpuset/ repeatly.<br /> <br /> The race that cause this bug can be shown as below:<br /> <br /> (umount) | (cat /proc//cpuset)<br /> css_release | proc_cpuset_show<br /> css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id);<br /> css_free_rwork_fn | cgroup_path_ns(css-&gt;cgroup, ...);<br /> cgroup_destroy_root | mutex_lock(&amp;cgroup_mutex);<br /> rebind_subsystems |<br /> cgroup_free_root |<br /> | // cgrp was freed, UAF<br /> | cgroup_path_ns_locked(cgrp,..);<br /> <br /> When the cpuset is initialized, the root node top_cpuset.css.cgrp<br /> will point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will<br /> allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated<br /> &amp;cgroup_root.cgrp. When the umount operation is executed,<br /> top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.<br /> <br /> The problem is that when rebinding to cgrp_dfl_root, there are cases<br /> where the cgroup_root allocated by setting up the root for cgroup v1<br /> is cached. This could lead to a Use-After-Free (UAF) if it is<br /> subsequently freed. The descendant cgroups of cgroup v1 can only be<br /> freed after the css is released. However, the css of the root will never<br /> be released, yet the cgroup_root should be freed when it is unmounted.<br /> This means that obtaining a reference to the css of the root does<br /> not guarantee that css.cgrp-&gt;root will not be freed.<br /> <br /> Fix this problem by using rcu_read_lock in proc_cpuset_show().<br /> As cgroup_root is kfree_rcu after commit d23b5c577715<br /> ("cgroup: Make operations on the cgroup root_list RCU safe"),<br /> css-&gt;cgroup won&amp;#39;t be freed during the critical section.<br /> To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to<br /> replace task_get_css with task_css.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: initialize integrity buffer to zero before writing it to media<br /> <br /> Metadata added by bio_integrity_prep is using plain kmalloc, which leads<br /> to random kernel memory being written media. For PI metadata this is<br /> limited to the app tag that isn&amp;#39;t used by kernel generated metadata,<br /> but for non-PI metadata the entire buffer leaks kernel memory.<br /> <br /> Fix this by adding the __GFP_ZERO flag to allocations for writes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix deadlock between mddev_suspend and flush bio<br /> <br /> Deadlock occurs when mddev is being suspended while some flush bio is in<br /> progress. It is a complex issue.<br /> <br /> T1. the first flush is at the ending stage, it clears &amp;#39;mddev-&gt;flush_bio&amp;#39;<br /> and tries to submit data, but is blocked because mddev is suspended<br /> by T4.<br /> T2. the second flush sets &amp;#39;mddev-&gt;flush_bio&amp;#39;, and attempts to queue<br /> md_submit_flush_data(), which is already running (T1) and won&amp;#39;t<br /> execute again if on the same CPU as T1.<br /> T3. the third flush inc active_io and tries to flush, but is blocked because<br /> &amp;#39;mddev-&gt;flush_bio&amp;#39; is not NULL (set by T2).<br /> T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc<br /> by T3.<br /> <br /> T1 T2 T3 T4<br /> (flush 1) (flush 2) (third 3) (suspend)<br /> md_submit_flush_data<br /> mddev-&gt;flush_bio = NULL;<br /> .<br /> . md_flush_request<br /> . mddev-&gt;flush_bio = bio<br /> . queue submit_flushes<br /> . .<br /> . . md_handle_request<br /> . . active_io + 1<br /> . . md_flush_request<br /> . . wait !mddev-&gt;flush_bio<br /> . .<br /> . . mddev_suspend<br /> . . wait !active_io<br /> . .<br /> . submit_flushes<br /> . queue_work md_submit_flush_data<br /> . //md_submit_flush_data is already running (T1)<br /> .<br /> md_handle_request<br /> wait resume<br /> <br /> The root issue is non-atomic inc/dec of active_io during flush process.<br /> active_io is dec before md_submit_flush_data is queued, and inc soon<br /> after md_submit_flush_data() run.<br /> md_flush_request<br /> active_io + 1<br /> submit_flushes<br /> active_io - 1<br /> md_submit_flush_data<br /> md_handle_request<br /> active_io + 1<br /> make_request<br /> active_io - 1<br /> <br /> If active_io is dec after md_handle_request() instead of within<br /> submit_flushes(), make_request() can be called directly intead of<br /> md_handle_request() in md_submit_flush_data(), and active_io will<br /> only inc and dec once in the whole flush process. Deadlock will be<br /> fixed.<br /> <br /> Additionally, the only difference between fixing the issue and before is<br /> that there is no return error handling of make_request(). But after<br /> previous patch cleaned md_write_start(), make_requst() only return error<br /> in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456,<br /> md/raid456: fix a deadlock for dm-raid456 while io concurrent with<br /> reshape)". Since dm always splits data and flush operation into two<br /> separate io, io size of flush submitted by dm always is 0, make_request()<br /> will not be called in md_submit_flush_data(). To prevent future<br /> modifications from introducing issues, add WARN_ON to ensure<br /> make_request() no error is returned in this context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma: fix call order in dmam_free_coherent<br /> <br /> dmam_free_coherent() frees a DMA allocation, which makes the<br /> freed vaddr available for reuse, then calls devres_destroy()<br /> to remove and free the data structure used to track the DMA<br /> allocation. Between the two calls, it is possible for a<br /> concurrent task to make an allocation with the same vaddr<br /> and add it to the devres list.<br /> <br /> If this happens, there will be two entries in the devres list<br /> with the same vaddr and devres_destroy() can free the wrong<br /> entry, triggering the WARN_ON() in dmam_match.<br /> <br /> Fix by destroying the devres entry before freeing the DMA<br /> allocation.<br /> <br /> kokonut //net/encryption<br /> http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix array-index-out-of-bounds in diFree