Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Do not change route.addr.src_addr outside state checks<br /> <br /> If the state is not idle then resolve_prepare_src() should immediately<br /> fail and no change to global state should happen. However, it<br /> unconditionally overwrites the src_addr trying to build a temporary any<br /> address.<br /> <br /> For instance if the state is already RDMA_CM_LISTEN then this will corrupt<br /> the src_addr and would cause the test in cma_cancel_operation():<br /> <br /> if (cma_any_addr(cma_src_addr(id_priv)) &amp;&amp; !id_priv-&gt;cma_dev)<br /> <br /> Which would manifest as this trace from syzkaller:<br /> <br /> BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26<br /> Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204<br /> <br /> CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:79 [inline]<br /> dump_stack+0x141/0x1d7 lib/dump_stack.c:120<br /> print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232<br /> __kasan_report mm/kasan/report.c:399 [inline]<br /> kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416<br /> __list_add_valid+0x93/0xa0 lib/list_debug.c:26<br /> __list_add include/linux/list.h:67 [inline]<br /> list_add_tail include/linux/list.h:100 [inline]<br /> cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]<br /> rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751<br /> ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102<br /> ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732<br /> vfs_write+0x28e/0xa30 fs/read_write.c:603<br /> ksys_write+0x1ee/0x250 fs/read_write.c:658<br /> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> This is indicating that an rdma_id_private was destroyed without doing<br /> cma_cancel_listens().<br /> <br /> Instead of trying to re-use the src_addr memory to indirectly create an<br /> any address derived from the dst build one explicitly on the stack and<br /> bind to that as any other normal flow would do. rdma_bind_addr() will copy<br /> it over the src_addr once it knows the state is valid.<br /> <br /> This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change<br /> route.addr.src_addr.ss_family")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: get rid of warning on transaction commit when using flushoncommit<br /> <br /> When using the flushoncommit mount option, during almost every transaction<br /> commit we trigger a warning from __writeback_inodes_sb_nr():<br /> <br /> $ cat fs/fs-writeback.c:<br /> (...)<br /> static void __writeback_inodes_sb_nr(struct super_block *sb, ...<br /> {<br /> (...)<br /> WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));<br /> (...)<br /> }<br /> (...)<br /> <br /> The trace produced in dmesg looks like the following:<br /> <br /> [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3<br /> [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif<br /> [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186<br /> [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3<br /> [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)<br /> [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246<br /> [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000<br /> [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50<br /> [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000<br /> [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488<br /> [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460<br /> [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000<br /> [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0<br /> [947.571072] Call Trace:<br /> [947.572354] <br /> [947.573266] btrfs_commit_transaction+0x1f1/0x998<br /> [947.576785] ? start_transaction+0x3ab/0x44e<br /> [947.579867] ? schedule_timeout+0x8a/0xdd<br /> [947.582716] transaction_kthread+0xe9/0x156<br /> [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407<br /> [947.590104] kthread+0x131/0x139<br /> [947.592168] ? set_kthread_struct+0x32/0x32<br /> [947.595174] ret_from_fork+0x22/0x30<br /> [947.597561] <br /> [947.598553] ---[ end trace 644721052755541c ]---<br /> <br /> This is because we started using writeback_inodes_sb() to flush delalloc<br /> when committing a transaction (when using -o flushoncommit), in order to<br /> avoid deadlocks with filesystem freeze operations. This change was made<br /> by commit ce8ea7cc6eb313 ("btrfs: don&amp;#39;t call btrfs_start_delalloc_roots<br /> in flushoncommit"). After that change we started producing that warning,<br /> and every now and then a user reports this since the warning happens too<br /> often, it spams dmesg/syslog, and a user is unsure if this reflects any<br /> problem that might compromise the filesystem&amp;#39;s reliability.<br /> <br /> We can not just lock the sb-&gt;s_umount semaphore before calling<br /> writeback_inodes_sb(), because that would at least deadlock with<br /> filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()<br /> is called while we are holding that semaphore in write mode, and that can<br /> trigger a transaction commit, resulting in a deadlock. It would also<br /> trigger the same type of deadlock in the unmount path. Possibly, it could<br /> also introduce some other locking dependencies that lockdep would report.<br /> <br /> To fix this call try_to_writeback_inodes_sb() instead of<br /> writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount<br /> and then will only call writeback_inodes_sb() if it was able to lock it.<br /> This is fine because the cases where it can&amp;#39;t read lock sb-&gt;s_umount<br /> are during a filesystem unmount or during a filesystem freeze - in those<br /> cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which<br /> calls writeback_inodes_sb(). In other words, in all cases where we can&amp;#39;t<br /> take a read lock on sb-&gt;s_umount, writeback is already being triggered<br /> elsewhere.<br /> <br /> An alternative would be to call btrfs_start_delalloc_roots() with a<br /> number of pages different from LONG_MAX, for example matching the number<br /> of delalloc bytes we currently have, in <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmvnic: free reset-work-item when flushing<br /> <br /> Fix a tiny memory leak when flushing the reset work queue.