Vulnerabilities

A hardcoded decryption key in Thinkware Cloud APK v4.3.46 allows attackers to access sensitive data and execute arbitrary commands with elevated privileges.

The Accessibility by AllAccessible plugin for WordPress is vulnerable to unauthorized modification of data that can lead to privilege escalation due to a missing capability check on the 'AllAccessible_save_settings' function in all versions up to, and including, 1.3.4. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update arbitrary options on the WordPress site. This can be leveraged to update the default role for registration to administrator and enable user registration for attackers to gain administrative user access to a vulnerable site.

The GriceMobile com.grice.call application 4.5.2 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.iui.mobile.presentation.MobileActivity.

The Mister org.mistergroup.shouldianswer application 1.4.264 for Android enables any installed application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the org.mistergroup.shouldianswer.ui.default_dialer.DefaultDialerActivity component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: terminate outstanding dump on socket close<br /> <br /> Netlink supports iterative dumping of data. It provides the families<br /> the following ops:<br /> - start - (optional) kicks off the dumping process<br /> - dump - actual dump helper, keeps getting called until it returns 0<br /> - done - (optional) pairs with .start, can be used for cleanup<br /> The whole process is asynchronous and the repeated calls to .dump<br /> don&amp;#39;t actually happen in a tight loop, but rather are triggered<br /> in response to recvmsg() on the socket.<br /> <br /> This gives the user full control over the dump, but also means that<br /> the user can close the socket without getting to the end of the dump.<br /> To make sure .start is always paired with .done we check if there<br /> is an ongoing dump before freeing the socket, and if so call .done.<br /> <br /> The complication is that sockets can get freed from BH and .done<br /> is allowed to sleep. So we use a workqueue to defer the call, when<br /> needed.<br /> <br /> Unfortunately this does not work correctly. What we defer is not<br /> the cleanup but rather releasing a reference on the socket.<br /> We have no guarantee that we own the last reference, if someone<br /> else holds the socket they may release it in BH and we&amp;#39;re back<br /> to square one.<br /> <br /> The whole dance, however, appears to be unnecessary. Only the user<br /> can interact with dumps, so we can clean up when socket is closed.<br /> And close always happens in process context. Some async code may<br /> still access the socket after close, queue notification skbs to it etc.<br /> but no dumps can start, end or otherwise make progress.<br /> <br /> Delete the workqueue and flush the dump state directly from the release<br /> handler. Note that further cleanup is possible in -next, for instance<br /> we now always call .done before releasing the main module reference,<br /> so dump doesn&amp;#39;t have to take a reference of its own.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix possible UAF in sctp_v6_available()<br /> <br /> A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints<br /> that sctp_v6_available() is calling dev_get_by_index_rcu()<br /> and ipv6_chk_addr() without holding rcu.<br /> <br /> [1]<br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.12.0-rc5-virtme #1216 Tainted: G W<br /> -----------------------------<br /> net/core/dev.c:876 RCU-list traversed in non-reader section!!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by sctp_hello/31495:<br /> #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp<br /> <br /> stack backtrace:<br /> CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:123)<br /> lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)<br /> dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))<br /> sctp_v6_available (net/sctp/ipv6.c:701) sctp<br /> sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp<br /> sctp_bind (net/sctp/socket.c:320) sctp<br /> inet6_bind_sk (net/ipv6/af_inet6.c:465)<br /> ? security_socket_bind (security/security.c:4581 (discriminator 1))<br /> __sys_bind (net/socket.c:1848 net/socket.c:1869)<br /> ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)<br /> ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))<br /> __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))<br /> do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f59b934a1e7<br /> Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48<br /> All code<br /> ========<br /> 0: 44 00 00 add %r8b,(%rax)<br /> 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43<br /> a: f7 d8 neg %eax<br /> c: 64 89 02 mov %eax,%fs:(%rdx)<br /> f: b8 ff ff ff ff mov $0xffffffff,%eax<br /> 14: eb bd jmp 0xffffffffffffffd3<br /> 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)<br /> 1d: 00 00 00<br /> 20: 0f 1f 00 nopl (%rax)<br /> 23: b8 31 00 00 00 mov $0x31,%eax<br /> 28: 0f 05 syscall<br /> 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/oa: Fix "Missing outer runtime PM protection" warning<br /> <br /> Fix the following drm_WARN:<br /> <br /> [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection<br /> ...<br /> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe]<br /> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe]<br /> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe]<br /> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe]<br /> [953.587515] xe_oa_release+0x9c/0xc0 [xe]<br /> <br /> (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Handle dml allocation failure to avoid crash<br /> <br /> [Why]<br /> In the case where a dml allocation fails for any reason, the<br /> current state&amp;#39;s dml contexts would no longer be valid. Then<br /> subsequent calls dc_state_copy_internal would shallow copy<br /> invalid memory and if the new state was released, a double<br /> free would occur.<br /> <br /> [How]<br /> Reset dml pointers in new_state to NULL and avoid invalid<br /> pointer<br /> <br /> (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx93-blk-ctrl: correct remove path<br /> <br /> The check condition should be &amp;#39;i onecell_data.num_domains&amp;#39;, not<br /> &amp;#39;bc-&gt;onecell_data.num_domains&amp;#39; which will make the look never finish<br /> and cause kernel panic.<br /> <br /> Also disable runtime to address<br /> "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN<br /> <br /> Hide KVM&amp;#39;s pt_mode module param behind CONFIG_BROKEN, i.e. disable support<br /> for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are<br /> myriad bugs in the implementation, some of which are fatal to the guest,<br /> and others which put the stability and health of the host at risk.<br /> <br /> For guest fatalities, the most glaring issue is that KVM fails to ensure<br /> tracing is disabled, and *stays* disabled prior to VM-Enter, which is<br /> necessary as hardware disallows loading (the guest&amp;#39;s) RTIT_CTL if tracing<br /> is enabled (enforced via a VMX consistency check). Per the SDM:<br /> <br /> If the logical processor is operating with Intel PT enabled (if<br /> IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load<br /> IA32_RTIT_CTL" VM-entry control must be 0.<br /> <br /> On the host side, KVM doesn&amp;#39;t validate the guest CPUID configuration<br /> provided by userspace, and even worse, uses the guest configuration to<br /> decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring<br /> guest CPUID to enumerate more address ranges than are supported in hardware<br /> will result in KVM trying to passthrough, save, and load non-existent MSRs,<br /> which generates a variety of WARNs, ToPA ERRORs in the host, a potential<br /> deadlock, etc.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: fix cacheflush with PAN<br /> <br /> It seems that the cacheflush syscall got broken when PAN for LPAE was<br /> implemented. User access was not enabled around the cache maintenance<br /> instructions, causing them to fault.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: kTLS, Fix incorrect page refcounting<br /> <br /> The kTLS tx handling code is using a mix of get_page() and<br /> page_ref_inc() APIs to increment the page reference. But on the release<br /> path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.<br /> <br /> This is an issue when using pages from large folios: the get_page()<br /> references are stored on the folio page while the page_ref_inc()<br /> references are stored directly in the given page. On release the folio<br /> page will be dereferenced too many times.<br /> <br /> This was found while doing kTLS testing with sendfile() + ZC when the<br /> served file was read from NFS on a kernel with NFS large folios support<br /> (commit 49b29a573da8 ("nfs: add support for large folios")).