Vulnerabilities

The application is vulnerable to SQL injection attacks. An attacker is able to dump the PostgreSQL database and read its content.

Several credentials for the local PostgreSQL database are stored in plain text (partially base64 encoded).

System environment variables are recorded in Docker Desktop diagnostic logs, when using shell auto-completion. This leads to unintentional disclosure of sensitive information such as api keys, passwords, etc. <br /> A malicious actor with read access to these logs could obtain secrets and further use them to gain unauthorized access to other systems. Starting with version 4.43.0 Docker Desktop no longer logs system environment variables as part of diagnostics log collection.

Incorrect Authorization vulnerability in OpenText™ GroupWise allows Exploiting Incorrectly Configured Access Control Security Levels.<br /> <br /> The vulnerability could allow unauthorized access to calendar items marked private.<br /> <br /> This issue affects GroupWise versions 7 through 17.5, 23.4, 24.1, 24.2, 24.3, 24.4.

Multiple plugins for WordPress are vulnerable to Stored Cross-Site Scripting via the plugin&amp;#39;s bundled Magnific Popups library (version 1.1.0) in various versions 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. NOTE: This vulnerability was fixed in the upstream library (Magnific Popups version 1.2.0) by disabling the loading of HTML within certain fields by default.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: marvell/cesa - Handle zero-length skcipher requests<br /> <br /> Do not access random memory for zero-length skcipher requests.<br /> Just return 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix ktls panic with sockmap<br /> <br /> [ 2172.936997] ------------[ cut here ]------------<br /> [ 2172.936999] kernel BUG at lib/iov_iter.c:629!<br /> ......<br /> [ 2172.944996] PKRU: 55555554<br /> [ 2172.945155] Call Trace:<br /> [ 2172.945299] <br /> [ 2172.945428] ? die+0x36/0x90<br /> [ 2172.945601] ? do_trap+0xdd/0x100<br /> [ 2172.945795] ? iov_iter_revert+0x178/0x180<br /> [ 2172.946031] ? iov_iter_revert+0x178/0x180<br /> [ 2172.946267] ? do_error_trap+0x7d/0x110<br /> [ 2172.946499] ? iov_iter_revert+0x178/0x180<br /> [ 2172.946736] ? exc_invalid_op+0x50/0x70<br /> [ 2172.946961] ? iov_iter_revert+0x178/0x180<br /> [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 2172.947446] ? iov_iter_revert+0x178/0x180<br /> [ 2172.947683] ? iov_iter_revert+0x5c/0x180<br /> [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840<br /> [ 2172.948206] tls_sw_sendmsg+0x52/0x80<br /> [ 2172.948420] ? inet_sendmsg+0x1f/0x70<br /> [ 2172.948634] __sys_sendto+0x1cd/0x200<br /> [ 2172.948848] ? find_held_lock+0x2b/0x80<br /> [ 2172.949072] ? syscall_trace_enter+0x140/0x270<br /> [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170<br /> [ 2172.949595] ? find_held_lock+0x2b/0x80<br /> [ 2172.949817] ? syscall_trace_enter+0x140/0x270<br /> [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190<br /> [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0<br /> [ 2172.951036] __x64_sys_sendto+0x24/0x30<br /> [ 2172.951382] do_syscall_64+0x90/0x170<br /> ......<br /> <br /> After calling bpf_exec_tx_verdict(), the size of msg_pl-&gt;sg may increase,<br /> e.g., when the BPF program executes bpf_msg_push_data().<br /> <br /> If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,<br /> it will return -ENOSPC and attempt to roll back to the non-zero copy<br /> logic. However, during rollback, msg-&gt;msg_iter is reset, but since<br /> msg_pl-&gt;sg.size has been increased, subsequent executions will exceed the<br /> actual size of msg_iter.<br /> &amp;#39;&amp;#39;&amp;#39;<br /> iov_iter_revert(&amp;msg-&gt;msg_iter, msg_pl-&gt;sg.size - orig_size);<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The changes in this commit are based on the following considerations:<br /> <br /> 1. When cork_bytes is set, rolling back to non-zero copy logic is<br /> pointless and can directly go to zero-copy logic.<br /> <br /> 2. We can not calculate the correct number of bytes to revert msg_iter.<br /> <br /> Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes<br /> by the BPF program, it becomes 11-byte data: "abc?de?fgh?".<br /> Then, we set cork_bytes to 6, which means the first 6 bytes have been<br /> processed, and the remaining 5 bytes "?fgh?" will be cached until the<br /> length meets the cork_bytes requirement.<br /> <br /> However, some data in "?fgh?" is not within &amp;#39;sg-&gt;msg_iter&amp;#39;<br /> (but in msg_pl instead), especially the data "?" we pushed.<br /> <br /> So it doesn&amp;#39;t seem as simple as just reverting through an offset of<br /> msg_iter.<br /> <br /> 3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,<br /> the user-space send() doesn&amp;#39;t return an error, and the returned length is<br /> the same as the input length parameter, even if some data is cached.<br /> <br /> Additionally, I saw that the current non-zero-copy logic for handling<br /> corking is written as:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> line 1177<br /> else if (ret != -EAGAIN) {<br /> if (ret == -ENOSPC)<br /> ret = 0;<br /> goto send_end;<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> So it&amp;#39;s ok to just return &amp;#39;copied&amp;#39; without error when a "cork" situation<br /> occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: handle hdr_first_de() return value<br /> <br /> The hdr_first_de() function returns a pointer to a struct NTFS_DE. This<br /> pointer may be NULL. To handle the NULL error effectively, it is important<br /> to implement an error handler. This will help manage potential errors<br /> consistently.<br /> <br /> Additionally, error handling for the return value already exists at other<br /> points where this function is called.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm-ni: Unregister PMUs on probe failure<br /> <br /> When a resource allocation fails in one clock domain of an NI device,<br /> we need to properly roll back all previously registered perf PMUs in<br /> other clock domains of the same device.<br /> <br /> Otherwise, it can lead to kernel panics.<br /> <br /> Calling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374<br /> arm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000<br /> arm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16<br /> list_add corruption: next-&gt;prev should be prev (fffffd01e9698a18),<br /> but was 0000000000000000. (next=ffff10001a0decc8).<br /> pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : list_add_valid_or_report+0x7c/0xb8<br /> lr : list_add_valid_or_report+0x7c/0xb8<br /> Call trace:<br /> __list_add_valid_or_report+0x7c/0xb8<br /> perf_pmu_register+0x22c/0x3a0<br /> arm_ni_probe+0x554/0x70c [arm_ni]<br /> platform_probe+0x70/0xe8<br /> really_probe+0xc6/0x4d8<br /> driver_probe_device+0x48/0x170<br /> __driver_attach+0x8e/0x1c0<br /> bus_for_each_dev+0x64/0xf0<br /> driver_add+0x138/0x260<br /> bus_add_driver+0x68/0x138<br /> __platform_driver_register+0x2c/0x40<br /> arm_ni_init+0x14/0x2a [arm_ni]<br /> do_init_module+0x36/0x298<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops - BUG: Fatal exception<br /> SMP: stopping secondary CPUs

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: Avoid clobbering kernel FPSIMD state with SMSTOP<br /> <br /> On system with SME, a thread&amp;#39;s kernel FPSIMD state may be erroneously<br /> clobbered during a context switch immediately after that state is<br /> restored. Systems without SME are unaffected.<br /> <br /> If the CPU happens to be in streaming SVE mode before a context switch<br /> to a thread with kernel FPSIMD state, fpsimd_thread_switch() will<br /> restore the kernel FPSIMD state using fpsimd_load_kernel_state() while<br /> the CPU is still in streaming SVE mode. When fpsimd_thread_switch()<br /> subsequently calls fpsimd_flush_cpu_state(), this will execute an<br /> SMSTOP, causing an exit from streaming SVE mode. The exit from<br /> streaming SVE mode will cause the hardware to reset a number of<br /> FPSIMD/SVE/SME registers, clobbering the FPSIMD state.<br /> <br /> Fix this by calling fpsimd_flush_cpu_state() before restoring the kernel<br /> FPSIMD state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: Discard stale CPU state when handling SME traps<br /> <br /> The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state<br /> incorrectly, and a race with preemption can result in a task having<br /> TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state<br /> is stale (e.g. with SME traps enabled). This can result in warnings from<br /> do_sme_acc() where SME traps are not expected while TIF_SME is set:<br /> <br /> | /* With TIF_SME userspace shouldn&amp;#39;t generate any traps */<br /> | if (test_and_set_thread_flag(TIF_SME))<br /> | WARN_ON(1);<br /> <br /> This is very similar to the SVE issue we fixed in commit:<br /> <br /> 751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")<br /> <br /> The race can occur when the SME trap handler is preempted before and<br /> after manipulating the saved FPSIMD/SVE/SME state, starting and ending on<br /> the same CPU, e.g.<br /> <br /> | void do_sme_acc(unsigned long esr, struct pt_regs *regs)<br /> | {<br /> | // Trap on CPU 0 with TIF_SME clear, SME traps enabled<br /> | // task-&gt;fpsimd_cpu is 0.<br /> | // per_cpu_ptr(&amp;fpsimd_last_state, 0) is task.<br /> |<br /> | ...<br /> |<br /> | // Preempted; migrated from CPU 0 to CPU 1.<br /> | // TIF_FOREIGN_FPSTATE is set.<br /> |<br /> | get_cpu_fpsimd_context();<br /> |<br /> | /* With TIF_SME userspace shouldn&amp;#39;t generate any traps */<br /> | if (test_and_set_thread_flag(TIF_SME))<br /> | WARN_ON(1);<br /> |<br /> | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {<br /> | unsigned long vq_minus_one =<br /> | sve_vq_from_vl(task_get_sme_vl(current)) - 1;<br /> | sme_set_vq(vq_minus_one);<br /> |<br /> | fpsimd_bind_task_to_cpu();<br /> | }<br /> |<br /> | put_cpu_fpsimd_context();<br /> |<br /> | // Preempted; migrated from CPU 1 to CPU 0.<br /> | // task-&gt;fpsimd_cpu is still 0<br /> | // If per_cpu_ptr(&amp;fpsimd_last_state, 0) is still task then:<br /> | // - Stale HW state is reused (with SME traps enabled)<br /> | // - TIF_FOREIGN_FPSTATE is cleared<br /> | // - A return to userspace skips HW state restore<br /> | }<br /> <br /> Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set<br /> by calling fpsimd_flush_task_state() to detach from the saved CPU<br /> state. This ensures that a subsequent context switch will not reuse the<br /> stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the<br /> new state to be reloaded from memory prior to a return to userspace.<br /> <br /> Note: this was originallly posted as [1].<br /> <br /> [ Rutland: rewrite commit message ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: max77705: Fix workqueue error handling in probe<br /> <br /> The create_singlethread_workqueue() doesn&amp;#39;t return error pointers, it<br /> returns NULL. Also cleanup the workqueue on the error paths.