deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48758
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put()

The bnx2fc_destroy() functions are removing the interface before calling
destroy_work. This results multiple WARNings from sysfs_remove_group() as
the controller rport device attributes are removed too early.

Replace the fcoe_port's destroy_work queue. It's not needed.

The problem is easily reproducible with the following steps.

Example:

  $ dmesg -w &
  $ systemctl enable --now fcoe
  $ fipvlan -s -c ens2f1
  $ fcoeadm -d ens2f1.802
  [  583.464488] host2: libfc: Link down on port (7500a1)
  [  583.472651] bnx2fc: 7500a1 - rport not created Yet!!
  [  583.490468] ------------[ cut here ]------------
  [  583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0'
  [  583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_remove_group+0x6f/0x80
  [  583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ...
  [  583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainted 5.14.0-39.el9.x86_64 #1
  [  583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
  [  584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_fc]
  [  584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80
  [  584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ...
  [  584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282
  [  584.188225] RAX: [PII_REDACTED] RBX: ffffffff8eec4220 RCX: [PII_REDACTED]
  [  584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c1586cd7cc0
  [  584.255089] RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffffb567c15afc00
  [  584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c[PII_REDACTED]
  [  584.322356] R13: ffff8c[PII_REDACTED] R14: ffff8c1483a4a000 R15: [PII_REDACTED]
  [  584.355379] FS:  [PII_REDACTED](0000) GS:ffff8c1586cc0000(0000) knlGS:[PII_REDACTED]
  [  584.394419] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  [  584.421123] CR2: 00007fe95a6f7840 CR3: [PII_REDACTED] CR4:[PII_REDACTED]0606e0
  [  584.454888] Call Trace:
  [  584.466108]  device_del+0xb2/0x3e0
  [  584.481701]  device_unregister+0x13/0x60
  [  584.501306]  bsg_unregister_queue+0x5b/0x80
  [  584.522029]  bsg_remove_queue+0x1c/0x40
  [  584.541884]  fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc]
  [  584.573823]  process_one_work+0x1e3/0x3b0
  [  584.592396]  worker_thread+0x50/0x3b0
  [  584.609256]  ? rescuer_thread+0x370/0x370
  [  584.628877]  kthread+0x149/0x170
  [  584.643673]  ? set_kthread_struct+0x40/0x40
  [  584.662909]  ret_from_fork+0x22/0x30
  [  584.680002] ---[ end trace 53575ecefa942ece ]---
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00849de10f798a[PII_REDACTED]a51b1756e7110754; https://git.kernel.org/stable/c/262550f29c750f7876b6ed1244281e72b64ebffb; https://git.kernel.org/stable/c/2a12fe8248a38437b95b942bbe85aced72e6e2eb
CVE: CVE-2022-48760
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: core: Fix hang in usb_kill_urb by adding memory barriers

The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return.  It turns out the issue is not unlinking
the URB; that works just fine.  Rather, the problem arises when the
wakeup notification that the URB has completed is not received.

The reason is memory-access ordering on SMP systems.  In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:

CPU 0					CPU 1
----------------------------		---------------------------------
usb_kill_urb():				__usb_hcd_giveback_urb():
  ...					  ...
  atomic_inc(&urb->reject);		  atomic_dec(&urb->use_count);
  ...					  ...
  wait_event(usb_kill_urb_queue,
	atomic_read(&urb->use_count) == 0);
					  if (atomic_read(&urb->reject))
						wake_up(&usb_kill_urb_queue);

Confining your attention to urb->reject and urb->use_count, you can
see that the overall pattern of accesses on CPU 0 is:

	write urb->reject, then read urb->use_count;

whereas the overall pattern of accesses on CPU 1 is:

	write urb->use_count, then read urb->reject.

This pattern is referred to in memory-model circles as SB (for "Store
Buffering"), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes.  The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb->use_count while CPU 1 sees the old
un-incremented value of urb->reject.  Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().

The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().

The problem is fixed by adding suitable memory barriers.  To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs.  The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.

This patch adds the necessary memory barriers.
CVSS Score: 7.1 (HIGH)
CWE: CWE-667
References: https://git.kernel.org/stable/c/26fbe9772b8c[PII_REDACTED]11444ce443011f86bf; https://git.kernel.org/stable/c/546ba238535d925254e0b3f12012a5c55801e2f3; https://git.kernel.org/stable/c/5904dfd3ddaff3bf4a41c3baf0a8e8f31ed4599b
CVE: CVE-2022-48761
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: xhci-plat: fix crash when suspend if remote wake enable

Crashed at i.mx8qm platform when suspend if enable remote wakeup

Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: [PII_REDACTED] x27: ffff00081193b578
x26: ffff00081193b570 x25: [PII_REDACTED] x24: [PII_REDACTED]
x23: ffff00081193a29c x22: [PII_REDACTED] x21: [PII_REDACTED]
x20: [PII_REDACTED] x19: ffff800014e90490 x18: [PII_REDACTED]
x17: [PII_REDACTED] x16: [PII_REDACTED] x15: [PII_REDACTED]
x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : ffff80001394baa0
x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 :[PII_REDACTED]53b453
x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : ffff00081193a29c
x2 : [PII_REDACTED] x1 : [PII_REDACTED] x0 : ffff[PII_REDACTED]20
Call trace:
 xhci_disable_hub_port_wake.isra.62+0x60/0xf8
 xhci_suspend+0x58/0x510
 xhci_plat_suspend+0x50/0x78
 platform_pm_suspend+0x2c/0x78
 dpm_run_callback.isra.25+0x50/0xe8
 __device_suspend+0x108/0x3c0

The basic flow:
	1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
        2. echo mem >/sys/power/state, system _device_suspend call xhci_suspend
        3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
	   but clock already gated by run time suspend.

This problem was hidden by power domain driver, which call run time resume before it.

But the below commit remove it and make this issue happen.
	commit c1df456d0f06e ("PM: domains: Don't runtime resume devices at genpd_prepare()")

This patch call run time resume before suspend to make sure clock is on
before access register.

Testeb-by: Abel Vesa <abel.vesa@nxp.com>
CVSS Score: 5.3 (MEDIUM)
References: https://git.kernel.org/stable/c/20c51a4c52208f98e27308c456a1951778f41fa5; https://git.kernel.org/stable/c/8b05ad29acb972850ad795fa850e814b2e758b83; https://git.kernel.org/stable/c/9df478463d9feb90dae24f183383961cf123a0ec
CVE: CVE-2022-48762
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: extable: fix load_unaligned_zeropad() reg indices

In ex_handler_load_unaligned_zeropad() we erroneously extract the data and
addr register indices from ex->type rather than ex->data. As ex->type will
contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
 * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is
   extracted from bits [9:5]. Thus, we may attempt to dereference an
   arbitrary address as X0 may hold an arbitrary value.
 * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is
   extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary
   behaviour within load_unaligned_zeropad() and its caller.

Fix this by extracting both values from ex->data as originally intended.

On an MTE-enabled QEMU image we are hitting the following crash:
 Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
 Call trace:
  fixup_exception+0xc4/0x108
  __do_kernel_fault+0x3c/0x268
  do_tag_check_fault+0x3c/0x104
  do_mem_abort+0x44/0xf4
  el1_abort+0x40/0x64
  el1h_64_sync_handler+0x60/0xa0
  el1h_64_sync+0x7c/0x80
  link_path_walk+0x150/0x344
  path_openat+0xa0/0x7dc
  do_filp_open+0xb8/0x168
  do_sys_openat2+0x88/0x17c
  __arm64_sys_openat+0x74/0xa0
  invoke_syscall+0x48/0x148
  el0_svc_common+0xb8/0xf8
  do_el0_svc+0x28/0x88
  el0_svc+0x24/0x84
  el0t_64_sync_handler+0x88/0xec
  el0t_64_sync+0x1b4/0x1b8
 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)
CVSS Score: 6.2 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239a; https://git.kernel.org/stable/c/47fe7a1c5e3e011eeb4ab79f2d54a794fdd1c3eb; https://git.kernel.org/stable/c/3758a6c74e08bdc15ccccd6872a6ad37d165239a
CVE: CVE-2022-48764
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}

Free the "struct kvm_cpuid_entry2" array on successful post-KVM_RUN
KVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()
free the array only on failure.

 BUG: memory leak
 unreferenced object 0xffff88810963a800 (size 2048):
  comm "syz-executor025", pid 3610, jiffies[PII_REDACTED] (age 8.080s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00  ................
    47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00  GenuntelineI....
  backtrace:
    [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline]
    [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580
    [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline]
    [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199
    [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423
    [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251
    [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066
    [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline]
    [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline]
    [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline]
    [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860
    [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/811f95ff95270e[PII_REDACTED]434d9301e3d7f07c; https://git.kernel.org/stable/c/b9ee734a14bb685b2088f2176d82b34cb4e30dbc; https://git.kernel.org/stable/c/811f95ff95270e[PII_REDACTED]434d9301e3d7f07c
CVE: CVE-2022-48765
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: LAPIC: Also cancel preemption timer during SET_LAPIC

The below warning is splatting during guest reboot.

  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  Call Trace:
   <TASK>
   kvm_vcpu_ioctl+0x279/0x710 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fd39797350b

This can be triggered by not exposing tsc-deadline mode and doing a reboot in
the guest. The lapic_shutdown() function which is called in sys_reboot path
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
switch between tsc-deadline and oneshot/periodic, which can result in preemption
timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
timer. Qemu will synchronise states around reset, let's cancel preemption timer
under KVM_SET_LAPIC.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/35fe7cfbab2e81f1afb23fc4212210b1de6d9633; https://git.kernel.org/stable/c/54b3439c8e70e0bcfea59aeef9dd98908cbbf655; https://git.kernel.org/stable/c/ce55f63f6cea4cab8ae9212f73285648a5baa30d
CVE: CVE-2022-48766
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.

Mirrors the logic for dcn30. Cue lots of WARNs and some
kernel panics without this fix.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f; https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341; https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f
CVE: CVE-2022-48767
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: properly put ceph_string reference after async create attempt

The reference acquired by try_prep_async_create is currently leaked.
Ensure we put it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/36d433ae3242aa[PII_REDACTED]50e6d1a5a3e78f18; https://git.kernel.org/stable/c/932a9b5870d38b87ba0a9923c804b1af7d3605b9; https://git.kernel.org/stable/c/a0c22e970cd78b81c94691e6cb09713e8074d580
CVE: CVE-2022-48768
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing/histogram: Fix a potential memory leak for kstrdup()

kfree() is missing on an error path to free the memory allocated by
kstrdup():

  p = param = kstrdup(data->params[i], GFP_KERNEL);

So it is better to free it via kfree(p).
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/8a8878ebb596281f50fc0b9a6e1f23f0d7f154e8; https://git.kernel.org/stable/c/d71b06aa995007eafd247626d0669b9364c42ad7; https://git.kernel.org/stable/c/df86e2fe808c3536a9dba353cc2bebdfea00d0cf
CVE: CVE-2022-48769
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

efi: runtime: avoid EFIv2 runtime services on Apple x86 machines

Aditya reports [0] that his recent MacbookPro crashes in the firmware
when using the variable services at runtime. The culprit appears to be a
call to QueryVariableInfo(), which we did not use to call on Apple x86
machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
firmware fairly recently, and QueryVariableInfo() (along with
UpdateCapsule() et al) was added in EFI v2.00.

The only runtime service introduced in EFI v2.00 that we actually use in
Linux is QueryVariableInfo(), as the capsule based ones are optional,
generally not used at runtime (all the LVFS/fwupd firmware update
infrastructure uses helper EFI programs that invoke capsule update at
boot time, not runtime), and not implemented by Apple machines in the
first place. QueryVariableInfo() is used to 'safely' set variables,
i.e., only when there is enough space. This prevents machines with buggy
firmwares from corrupting their NVRAMs when they run out of space.

Given that Apple machines have been using EFI v1.10 services only for
the longest time (the EFI v2.0 spec was released in 2006, and Linux
support for the newly introduced runtime services was added in 2011, but
the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
let's avoid the EFI v2.0 ones on all Apple x86 machines.

[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3df[PII_REDACTED]2ae15dcebf66beba1029df957b4; https://git.kernel.org/stable/c/a[PII_REDACTED]c825c321c9b55b8a9dc5a128a6684; https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807
CVE: CVE-2022-48770
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()

task_pt_regs() can return NULL on powerpc for kernel threads. This is
then used in __bpf_get_stack() to check for user mode, resulting in a
kernel oops. Guard against this by checking return value of
task_pt_regs() before trying to obtain the call chain.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0bcd484587b3b3092e448d27dc369e347e1810c3; https://git.kernel.org/stable/c/b82ef4985a6d05e80f[PII_REDACTED]30351df7b79a; https://git.kernel.org/stable/c/b992f01e66150fc5e90be4a96f5eb8e634c8249e
CVE: CVE-2022-48771
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Fix stale file descriptors on failed usercopy

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.

Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0008a0c78fc33a84e2212a7c04e6b21a36ca6f4d; https://git.kernel.org/stable/c/1d833b27fb708d6fdf5de9f6b3a8be4bd4321565; https://git.kernel.org/stable/c/[PII_REDACTED]fc6f437bc064f628cf9b0e4571c56c
CVE: CVE-2023-52883
Published: 2024-06-20
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Fix possible null pointer dereference

abo->tbo.resource may be NULL in amdgpu_vm_bo_update.
CVSS Score: 7.5 (HIGH)
CWE: CWE-476
References: https://git.kernel.org/stable/c/51b79f33817544e3b4df838d86e8e8e4388ff684; https://git.kernel.org/stable/c/fefac8c4686fd81fde6830c6dae32f9001d2ac28; https://git.kernel.org/stable/c/51b79f33817544e3b4df838d86e8e8e4388ff684
CVE: CVE-2024-6183
Published: 2024-06-20
Description: 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.
CVSS Score: 4.3 (MEDIUM)
CWE: CWE-80, CWE-79
References: https://vuldb.com/?ctiid.269154; https://vuldb.com/?id.269154; https://vuldb.com/?submit.353713
CVE: CVE-2024-6184
Published: 2024-06-20
Description: 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.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-78
References: https://github.com/L1OudFd8cl09/CVE/blob/main/11_06_2024_a.md; https://vuldb.com/?ctiid.269155; https://vuldb.com/?id.269155
CVE: CVE-2024-6185
Published: 2024-06-20
Description: 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.
CVSS Score: 6.3 (MEDIUM)
CWE: CWE-78
References: https://github.com/L1OudFd8cl09/CVE/blob/main/11_06_2024_b.md; https://vuldb.com/?ctiid.269156; https://vuldb.com/?id.269156
CVE: CVE-2023-49110
Published: 2024-06-20
Description: When the Kiuwan Local Analyzer uploads the scan results to the Kiuwan SAST web 
application (either on-premises or cloud/SaaS solution), the transmitted data 
consists of a ZIP archive containing several files, some of them in the 
XML file format. During Kiuwan's server-side processing of these XML 
files, it resolves external XML entities, resulting in a XML external 
entity injection attack. An attacker with privileges to scan 
source code within the "Code Security" module is able to extract any 
files of the operating system with the rights of the application server 
user and is potentially able to gain sensitive files, such as 
configuration and passwords. Furthermore, this vulnerability also allows
 an attacker to initiate connections to internal systems, e.g. for port 
scans or accessing other internal functions / applications such as the 
Wildfly admin console of Kiuwan.

This issue affects Kiuwan SAST: <master.1808.p685.q13371
CVSS Score: 7.2 (HIGH)
CWE: CWE-611
References: https://r.sec-consult.com/kiuwan; https://www.kiuwan.com/docs/display/K5/%5B2024-05-30%5D+Change+Log; http://seclists.org/fulldisclosure/2024/Jun/3
CVE: CVE-2023-49111
Published: 2024-06-20
Description: For Kiuwan installations with SSO (single sign-on) enabled, an 
unauthenticated reflected cross-site scripting attack can be performed 
on the login page "login.html". This is possible due to the request parameter "message" values
 being directly included in a JavaScript block in the response. This is 
especially critical in business environments using AD SSO 
authentication, e.g. via ADFS, where attackers could potentially steal 
AD passwords.



This issue affects Kiuwan SAST: <master.1808.p685.q13371
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-79
References: https://r.sec-consult.com/kiuwan; https://www.kiuwan.com/docs/display/K5/%5B2024-05-30%5D+Change+Log; http://seclists.org/fulldisclosure/2024/Jun/3
CVE: CVE-2023-49112
Published: 2024-06-20
Description: Kiuwan provides an API endpoint

/saas/rest/v1/info/application

to get information about any 
application, providing only its name via the "application" parameter. This endpoint lacks proper access 
control mechanisms, allowing other authenticated users to read 
information about applications, even though they have not been granted 
the necessary rights to do so.



This issue affects Kiuwan SAST: <master.1808.p685.q13371
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-639
References: https://r.sec-consult.com/kiuwan; https://www.kiuwan.com/docs/display/K5/%5B2024-05-30%5D+Change+Log; http://seclists.org/fulldisclosure/2024/Jun/3