Vulnerabilities

Kiuwan provides an API endpoint<br /> <br /> /saas/rest/v1/info/application<br /> <br /> to get information about any <br /> application, providing only its name via the "application" parameter. This endpoint lacks proper access <br /> control mechanisms, allowing other authenticated users to read <br /> information about applications, even though they have not been granted <br /> the necessary rights to do so.<br /> <br /> <br /> <br /> This issue affects Kiuwan SAST:

The Kiuwan Local Analyzer (KLA) Java scanning application contains several <br /> hard-coded secrets in plain text format. In some cases, this can <br /> potentially compromise the confidentiality of the scan results. Several credentials were found in the JAR files of the Kiuwan Local Analyzer.<br /> <br /> The<br /> JAR file "lib.engine/insight/optimyth-insight.jar" contains the file <br /> "InsightServicesConfig.properties", which has the configuration tokens <br /> "insight.github.user" as well as "insight.github.password" prefilled <br /> with credentials. At least the specified username corresponds to a valid<br /> GitHub account. The<br /> JAR file "lib.engine/insight/optimyth-insight.jar" also contains the <br /> file "es/als/security/Encryptor.properties", in which the key used for <br /> encrypting the results of any performed scan.<br /> <br /> <br /> <br /> <br /> This issue affects Kiuwan SAST:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: Fix stale file descriptors on failed usercopy<br /> <br /> A failing usercopy of the fence_rep object will lead to a stale entry in<br /> the file descriptor table as put_unused_fd() won&amp;#39;t release it. This<br /> enables userland to refer to a dangling &amp;#39;file&amp;#39; object through that still<br /> valid file descriptor, leading to all kinds of use-after-free<br /> exploitation scenarios.<br /> <br /> Fix this by deferring the call to fd_install() until after the usercopy<br /> has succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix possible null pointer dereference<br /> <br /> abo-&gt;tbo.resource may be NULL in amdgpu_vm_bo_update.

A vulnerability classified as problematic has been found in EZ-Suite EZ-Partner 5. Affected is an unknown function of the component Forgot Password Handler. The manipulation leads to basic cross site scripting. It is possible to launch the attack remotely. VDB-269154 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as critical was found in Ruijie RG-UAC 1.0. Affected by this vulnerability is an unknown functionality of the file /view/systemConfig/reboot/reboot_commit.php. The manipulation of the argument servicename leads to os command injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-269155. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability, which was classified as critical, has been found in Ruijie RG-UAC 1.0. Affected by this issue is the function get_ip_addr_details of the file /view/dhcp/dhcpConfig/commit.php. The manipulation of the argument ethname leads to os command injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269156. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev<br /> <br /> struct rpmsg_ctrldev contains a struct cdev. The current code frees<br /> the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the<br /> cdev is a managed object, therefore its release is not predictable<br /> and the rpmsg_ctrldev could be freed before the cdev is entirely<br /> released, as in the backtrace below.<br /> <br /> [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x7c<br /> [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_print_object+0x13c/0x1b0<br /> [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif_hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vmalloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v<br /> [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B 5.4.163-lockdep #26<br /> [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)<br /> [ 93.730055] Workqueue: events kobject_delayed_cleanup<br /> [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO)<br /> [ 93.740216] pc : debug_print_object+0x13c/0x1b0<br /> [ 93.744890] lr : debug_print_object+0x13c/0x1b0<br /> [ 93.749555] sp : ffffffacf5bc7940<br /> [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000<br /> [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000<br /> [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000<br /> [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0<br /> [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0<br /> [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0<br /> [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000<br /> [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c<br /> [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000<br /> [ 93.802244] x11: 0000000000000001 x10: 0000000000000000<br /> [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900<br /> [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000<br /> [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001<br /> [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061<br /> [ 93.835104] Call trace:<br /> [ 93.837644] debug_print_object+0x13c/0x1b0<br /> [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0<br /> [ 93.846987] debug_check_no_obj_freed+0x18/0x20<br /> [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4<br /> [ 93.856346] kfree+0xfc/0x2f4<br /> [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8<br /> [ 93.864445] device_release+0x84/0x168<br /> [ 93.868310] kobject_cleanup+0x12c/0x298<br /> [ 93.872356] kobject_delayed_cleanup+0x10/0x18<br /> [ 93.876948] process_one_work+0x578/0x92c<br /> [ 93.881086] worker_thread+0x804/0xcf8<br /> [ 93.884963] kthread+0x2a8/0x314<br /> [ 93.888303] ret_from_fork+0x10/0x18<br /> <br /> The cdev_device_add/del() API was created to address this issue (see<br /> commit &amp;#39;233ed09d7fda ("chardev: add helper function to register char<br /> devs with a struct device")&amp;#39;), use it instead of cdev add/del().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: core: Fix hang in usb_kill_urb by adding memory barriers<br /> <br /> The syzbot fuzzer has identified a bug in which processes hang waiting<br /> for usb_kill_urb() to return. It turns out the issue is not unlinking<br /> the URB; that works just fine. Rather, the problem arises when the<br /> wakeup notification that the URB has completed is not received.<br /> <br /> The reason is memory-access ordering on SMP systems. In outline form,<br /> usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on<br /> different CPUs perform the following actions:<br /> <br /> CPU 0 CPU 1<br /> ---------------------------- ---------------------------------<br /> usb_kill_urb(): __usb_hcd_giveback_urb():<br /> ... ...<br /> atomic_inc(&amp;urb-&gt;reject); atomic_dec(&amp;urb-&gt;use_count);<br /> ... ...<br /> wait_event(usb_kill_urb_queue,<br /> atomic_read(&amp;urb-&gt;use_count) == 0);<br /> if (atomic_read(&amp;urb-&gt;reject))<br /> wake_up(&amp;usb_kill_urb_queue);<br /> <br /> Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can<br /> see that the overall pattern of accesses on CPU 0 is:<br /> <br /> write urb-&gt;reject, then read urb-&gt;use_count;<br /> <br /> whereas the overall pattern of accesses on CPU 1 is:<br /> <br /> write urb-&gt;use_count, then read urb-&gt;reject.<br /> <br /> This pattern is referred to in memory-model circles as SB (for "Store<br /> Buffering"), and it is well known that without suitable enforcement of<br /> the desired order of accesses -- in the form of memory barriers -- it<br /> is entirely possible for one or both CPUs to execute their reads ahead<br /> of their writes. The end result will be that sometimes CPU 0 sees the<br /> old un-decremented value of urb-&gt;use_count while CPU 1 sees the old<br /> un-incremented value of urb-&gt;reject. Consequently CPU 0 ends up on<br /> the wait queue and never gets woken up, leading to the observed hang<br /> in usb_kill_urb().<br /> <br /> The same pattern of accesses occurs in usb_poison_urb() and the<br /> failure pathway of usb_hcd_submit_urb().<br /> <br /> The problem is fixed by adding suitable memory barriers. To provide<br /> proper memory-access ordering in the SB pattern, a full barrier is<br /> required on both CPUs. The atomic_inc() and atomic_dec() accesses<br /> themselves don&amp;#39;t provide any memory ordering, but since they are<br /> present, we can use the optimized smp_mb__after_atomic() memory<br /> barrier in the various routines to obtain the desired effect.<br /> <br /> This patch adds the necessary memory barriers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci-plat: fix crash when suspend if remote wake enable<br /> <br /> Crashed at i.mx8qm platform when suspend if enable remote wakeup<br /> <br /> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12<br /> Hardware name: Freescale i.MX8QM MEK (DT)<br /> Workqueue: events_unbound async_run_entry_fn<br /> pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8<br /> lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8<br /> sp : ffff80001394bbf0<br /> x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578<br /> x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001<br /> x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0<br /> x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453<br /> x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c<br /> x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620<br /> Call trace:<br /> xhci_disable_hub_port_wake.isra.62+0x60/0xf8<br /> xhci_suspend+0x58/0x510<br /> xhci_plat_suspend+0x50/0x78<br /> platform_pm_suspend+0x2c/0x78<br /> dpm_run_callback.isra.25+0x50/0xe8<br /> __device_suspend+0x108/0x3c0<br /> <br /> The basic flow:<br /> 1. run time suspend call xhci_suspend, xhci parent devices gate the clock.<br /> 2. echo mem &gt;/sys/power/state, system _device_suspend call xhci_suspend<br /> 3. xhci_suspend call xhci_disable_hub_port_wake, which access register,<br /> but clock already gated by run time suspend.<br /> <br /> This problem was hidden by power domain driver, which call run time resume before it.<br /> <br /> But the below commit remove it and make this issue happen.<br /> commit c1df456d0f06e ("PM: domains: Don&amp;#39;t runtime resume devices at genpd_prepare()")<br /> <br /> This patch call run time resume before suspend to make sure clock is on<br /> before access register.<br /> <br /> Testeb-by: Abel Vesa

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: extable: fix load_unaligned_zeropad() reg indices<br /> <br /> In ex_handler_load_unaligned_zeropad() we erroneously extract the data and<br /> addr register indices from ex-&gt;type rather than ex-&gt;data. As ex-&gt;type will<br /> contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):<br /> * We&amp;#39;ll always treat X0 as the address register, since EX_DATA_REG_ADDR is<br /> extracted from bits [9:5]. Thus, we may attempt to dereference an<br /> arbitrary address as X0 may hold an arbitrary value.<br /> * We&amp;#39;ll always treat X4 as the data register, since EX_DATA_REG_DATA is<br /> extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary<br /> behaviour within load_unaligned_zeropad() and its caller.<br /> <br /> Fix this by extracting both values from ex-&gt;data as originally intended.<br /> <br /> On an MTE-enabled QEMU image we are hitting the following crash:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> fixup_exception+0xc4/0x108<br /> __do_kernel_fault+0x3c/0x268<br /> do_tag_check_fault+0x3c/0x104<br /> do_mem_abort+0x44/0xf4<br /> el1_abort+0x40/0x64<br /> el1h_64_sync_handler+0x60/0xa0<br /> el1h_64_sync+0x7c/0x80<br /> link_path_walk+0x150/0x344<br /> path_openat+0xa0/0x7dc<br /> do_filp_open+0xb8/0x168<br /> do_sys_openat2+0x88/0x17c<br /> __arm64_sys_openat+0x74/0xa0<br /> invoke_syscall+0x48/0x148<br /> el0_svc_common+0xb8/0xf8<br /> do_el0_svc+0x28/0x88<br /> el0_svc+0x24/0x84<br /> el0t_64_sync_handler+0x88/0xec<br /> el0t_64_sync+0x1b4/0x1b8<br /> Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Forcibly leave nested virt when SMM state is toggled<br /> <br /> Forcibly leave nested virtualization operation if userspace toggles SMM<br /> state via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS. If userspace<br /> forces the vCPU out of SMM while it&amp;#39;s post-VMXON and then injects an SMI,<br /> vmx_enter_smm() will overwrite vmx-&gt;nested.smm.vmxon and end up with both<br /> vmxon=false and smm.vmxon=false, but all other nVMX state allocated.<br /> <br /> Don&amp;#39;t attempt to gracefully handle the transition as (a) most transitions<br /> are nonsencial, e.g. forcing SMM while L2 is running, (b) there isn&amp;#39;t<br /> sufficient information to handle all transitions, e.g. SVM wants access<br /> to the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede<br /> KVM_SET_NESTED_STATE during state restore as the latter disallows putting<br /> the vCPU into L2 if SMM is active, and disallows tagging the vCPU as<br /> being post-VMXON in SMM if SMM is not active.<br /> <br /> Abuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX<br /> due to failure to free vmcs01&amp;#39;s shadow VMCS, but the bug goes far beyond<br /> just a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU<br /> in an architecturally impossible state.<br /> <br /> WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]<br /> WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656<br /> Modules linked in:<br /> CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]<br /> RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656<br /> Code: 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00<br /> Call Trace:<br /> <br /> kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123<br /> kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]<br /> kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460<br /> kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]<br /> kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676<br /> kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]<br /> kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250<br /> kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273<br /> __fput+0x286/0x9f0 fs/file_table.c:311<br /> task_work_run+0xdd/0x1a0 kernel/task_work.c:164<br /> exit_task_work include/linux/task_work.h:32 [inline]<br /> do_exit+0xb29/0x2a30 kernel/exit.c:806<br /> do_group_exit+0xd2/0x2f0 kernel/exit.c:935<br /> get_signal+0x4b0/0x28c0 kernel/signal.c:2862<br /> arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868<br /> handle_signal_work kernel/entry/common.c:148 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:172 [inline]<br /> exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]<br /> syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300<br /> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br />