Vulnerabilities

A vulnerability has been found in Ruijie RG-UAC 1.0 and classified as critical. This vulnerability affects unknown code of the file /view/vpn/autovpn/sub_commit.php. The manipulation of the argument key leads to os command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-269158 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

When the Kiuwan Local Analyzer uploads the scan results to the Kiuwan SAST web <br /> application (either on-premises or cloud/SaaS solution), the transmitted data <br /> consists of a ZIP archive containing several files, some of them in the <br /> XML file format. During Kiuwan&amp;#39;s server-side processing of these XML <br /> files, it resolves external XML entities, resulting in a XML external <br /> entity injection attack. An attacker with privileges to scan <br /> source code within the "Code Security" module is able to extract any <br /> files of the operating system with the rights of the application server <br /> user and is potentially able to gain sensitive files, such as <br /> configuration and passwords. Furthermore, this vulnerability also allows<br /> an attacker to initiate connections to internal systems, e.g. for port <br /> scans or accessing other internal functions / applications such as the <br /> Wildfly admin console of Kiuwan.<br /> <br /> This issue affects Kiuwan SAST:

For Kiuwan installations with SSO (single sign-on) enabled, an <br /> unauthenticated reflected cross-site scripting attack can be performed <br /> on the login page "login.html". This is possible due to the request parameter "message" values<br /> being directly included in a JavaScript block in the response. This is <br /> especially critical in business environments using AD SSO <br /> authentication, e.g. via ADFS, where attackers could potentially steal <br /> AD passwords.<br /> <br /> <br /> <br /> This issue affects Kiuwan SAST:

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.