Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: tsc2046: fix memory corruption by preventing array overflow<br /> <br /> On one side we have indio_dev-&gt;num_channels includes all physical channels +<br /> timestamp channel. On other side we have an array allocated only for<br /> physical channels. So, fix memory corruption by ARRAY_SIZE() instead of<br /> num_channels variable.<br /> <br /> Note the first case is a cleanup rather than a fix as the software<br /> timestamp channel bit in active_scanmask is never set by the IIO core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: men_z188_adc: Fix a resource leak in an error handling path<br /> <br /> If iio_device_register() fails, a previous ioremap() is left unbalanced.<br /> <br /> Update the error handling path and add the missing iounmap() call, as<br /> already done in the remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix crash due to out of bounds access into reg2btf_ids.<br /> <br /> When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added<br /> kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier<br /> reg type to the appropriate btf_vmlinux BTF ID, however<br /> commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL")<br /> moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after<br /> the base register types, and defined other variants using type flag<br /> composition. However, now, the direct usage of reg-&gt;type to index into<br /> reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to<br /> out of bounds access and kernel crash on dereference of bad pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ib_srp: Fix a deadlock<br /> <br /> Remove the flush_workqueue(system_long_wq) call since flushing<br /> system_long_wq is deadlock-prone and since that call is redundant with a<br /> preceding cancel_work_sync()

The AcyMailing – An Ultimate Newsletter Plugin and Marketing Automation Solution for WordPress plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the acym_extractArchive function in all versions up to, and including, 9.7.2. This makes it possible for authenticated attackers, with Subscriber-level access and above, to upload arbitrary files on the affected site&amp;#39;s server which may make remote code execution possible.

The Themify Builder plugin for WordPress is vulnerable to unauthorized post duplication due to missing checks on the duplicate_page_ajaxify function in all versions up to, and including, 7.6.1. This makes it possible for authenticated attackers, with Contributor-level access and above, to duplicate and view private or draft posts created by other users that otherwise shouldn&amp;#39;t be accessible to them.

Dell Power Manager (DPM), versions 3.15.0 and prior, contains an Incorrect Privilege Assignment vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Code execution and Elevation of privileges.

The The Plus Addons for Elementor – Elementor Addons, Page Templates, Widgets, Mega Menu, WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the carousel_direction parameter of testimonials widget in all versions up to, and including, 5.6.2 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Fix fault in reweight_entity<br /> <br /> Syzbot found a GPF in reweight_entity. This has been bisected to<br /> commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid<br /> sched_task_group")<br /> <br /> There is a race between sched_post_fork() and setpriority(PRIO_PGRP)<br /> within a thread group that causes a null-ptr-deref in<br /> reweight_entity() in CFS. The scenario is that the main process spawns<br /> number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),<br /> wait, and exit. For each of the new threads the copy_process() gets<br /> invoked, which adds the new task_struct and calls sched_post_fork()<br /> for it.<br /> <br /> In the above scenario there is a possibility that<br /> setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread<br /> in the group that is just being created by copy_process(), and for<br /> which the sched_post_fork() has not been executed yet. This will<br /> trigger a null pointer dereference in reweight_entity(), as it will<br /> try to access the run queue pointer, which hasn&amp;#39;t been set.<br /> <br /> Before the mentioned change the cfs_rq pointer for the task has been<br /> set in sched_fork(), which is called much earlier in copy_process(),<br /> before the new task is added to the thread_group. Now it is done in<br /> the sched_post_fork(), which is called after that. To fix the issue<br /> the remove the update_load param from the update_load param() function<br /> and call reweight_task() only if the task flag doesn&amp;#39;t have the<br /> TASK_NEW flag set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: fix oops caused by irqsoff latency tracer<br /> <br /> The trace_hardirqs_{on,off}() require the caller to setup frame pointer<br /> properly. This because these two functions use macro &amp;#39;CALLER_ADDR1&amp;#39; (aka.<br /> __builtin_return_address(1)) to acquire caller info. If the $fp is used<br /> for other purpose, the code generated this macro (as below) could trigger<br /> memory access fault.<br /> <br /> 0xffffffff8011510e : ld a1,-16(s0)<br /> 0xffffffff80115112 : ld s2,-8(a1) #

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: prevent copying too big compressed lzo segment<br /> <br /> Compressed length can be corrupted to be a lot larger than memory<br /> we have allocated for buffer.<br /> This will cause memcpy in copy_compressed_segment to write outside<br /> of allocated memory.<br /> <br /> This mostly results in stuck read syscall but sometimes when using<br /> btrfs send can get #GP<br /> <br /> kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI<br /> kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12<br /> kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]<br /> kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs<br /> Code starting with the faulting instruction<br /> ===========================================<br /> 0:* 48 8b 06 mov (%rsi),%rax

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: int340x: fix memory leak in int3400_notify()<br /> <br /> It is easy to hit the below memory leaks in my TigerLake platform:<br /> <br /> unreferenced object 0xffff927c8b91dbc0 (size 32):<br /> comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s)<br /> hex dump (first 32 bytes):<br /> 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The<br /> 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.<br /> backtrace:<br /> [] __kmalloc_track_caller+0x2fe/0x4a0<br /> [] kvasprintf+0x65/0xd0<br /> [] kasprintf+0x4e/0x70<br /> [] int3400_notify+0x82/0x120 [int3400_thermal]<br /> [] acpi_ev_notify_dispatch+0x54/0x71<br /> [] acpi_os_execute_deferred+0x17/0x30<br /> [] process_one_work+0x21a/0x3f0<br /> [] worker_thread+0x4a/0x3b0<br /> [] kthread+0xfd/0x130<br /> [] ret_from_fork+0x1f/0x30<br /> <br /> Fix it by calling kfree() accordingly.