deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-32498
Published: 2024-07-05
Description: An issue was discovered in OpenStack Cinder through 24.0.0, Glance before 28.0.2, and Nova before 29.0.3. Arbitrary file access can occur via custom QCOW2 external data. By supplying a crafted QCOW2 image that references a specific data file path, an authenticated user may convince systems to return a copy of that file's contents from the server, resulting in unauthorized access to potentially sensitive data. All Cinder and Nova deployments are affected; only Glance deployments with image conversion enabled are affected.
CVSS Score: 6.5 (MEDIUM)
CWE: CWE-552
References: http://www.openwall.com/lists/oss-security/2024/07/02/2; https://launchpad.net/bugs/2059809; https://security.openstack.org/ossa/OSSA-2024-001.html
CVE: CVE-2024-34481
Published: 2024-07-05
Description: drupal-wiki.com Drupal Wiki before 8.31.1 allows XSS via comments, captions, and image titles of a Wiki page.
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-79, CWE-79
References: https://drupal-wiki.com/drupal-wiki-update-8-31/; https://seclists.org/fulldisclosure/2024/May/4; https://www.secuvera.de/advisories/secuvera-SA-2024-02.txt
CVE: CVE-2024-36041
Published: 2024-07-05
Description: KSmserver in KDE Plasma Workspace (aka plasma-workspace) before 5.27.11.1 and 6.x before 6.0.5.1 allows connections via ICE based purely on the host, i.e., all local connections are accepted. This allows another user on the same machine to gain access to the session manager, e.g., use the session-restore feature to execute arbitrary code as the victim (on the next boot) via earlier use of the /tmp directory.
CVSS Score: 7.8 (HIGH)
CWE: CWE-613
References: https://github.com/KDE/plasma-workspace/tags; https://invent.kde.org/plasma/plasma-workspace/; https://kde.org/info/security/advisory-20240531-1.txt
CVE: CVE-2024-39472
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

xfs: fix log recovery buffer allocation for the legacy h_size fixup

Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by
mkfs") added a fixup for incorrect h_size values used for the initial
umount record in old xfsprogs versions.  Later commit 0c771b99d6c9
("xfs: clean up calculation of LR header blocks") cleaned up the log
reover buffer calculation, but stoped using the fixed up h_size value
to size the log recovery buffer, which can lead to an out of bounds
access when the incorrect h_size does not come from the old mkfs
tool, but a fuzzer.

Fix this by open coding xlog_logrec_hblks and taking the fixed h_size
into account for this calculation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a; https://git.kernel.org/stable/c/57835c0e7152e36b03875dd6c56dfeed685c1b1f; https://git.kernel.org/stable/c/c2389c074973aa94e34992e7f66dac0de37595b5
CVE: CVE-2024-39473
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension

If a process module does not have base config extension then the same
format applies to all of it's inputs and the process->base_config_ext is
NULL, causing NULL dereference when specifically crafted topology and
sequences used.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368; https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6; https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8
CVE: CVE-2024-39474
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL

commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")
includes support for __GFP_NOFAIL, but it presents a conflict with commit
dd544141b9eb ("vmalloc: back off when the current task is OOM-killed").  A
possible scenario is as follows:

process-a
__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)
    __vmalloc_area_node()
        vm_area_alloc_pages()
		--> oom-killer send SIGKILL to process-a
        if (fatal_signal_pending(current)) break;
--> return NULL;

To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()
if __GFP_NOFAIL set.

This issue occurred during OPLUS KASAN TEST. Below is part of the log
-> oom-killer sends signal to process
[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198

[65731.259685] [T32454] Call trace:
[65731.259698] [T32454]  dump_backtrace+0xf4/0x118
[65731.259734] [T32454]  show_stack+0x18/0x24
[65731.259756] [T32454]  dump_stack_lvl+0x60/0x7c
[65731.259781] [T32454]  dump_stack+0x18/0x38
[65731.259800] [T32454]  mrdump_common_die+0x250/0x39c [mrdump]
[65731.259936] [T32454]  ipanic_die+0x20/0x34 [mrdump]
[65731.260019] [T32454]  atomic_notifier_call_chain+0xb4/0xfc
[65731.260047] [T32454]  notify_die+0x114/0x198
[65731.260073] [T32454]  die+0xf4/0x5b4
[65731.260098] [T32454]  die_kernel_fault+0x80/0x98
[65731.260124] [T32454]  __do_kernel_fault+0x160/0x2a8
[65731.260146] [T32454]  do_bad_area+0x68/0x148
[65731.260174] [T32454]  do_mem_abort+0x151c/0x1b34
[65731.260204] [T32454]  el1_abort+0x3c/0x5c
[65731.260227] [T32454]  el1h_64_sync_handler+0x54/0x90
[65731.260248] [T32454]  el1h_64_sync+0x68/0x6c

[65731.260269] [T32454]  z_erofs_decompress_queue+0x7f0/0x2258
--> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);
	kernel panic by NULL pointer dereference.
	erofs assume kvmalloc with __GFP_NOFAIL never return NULL.
[65731.260293] [T32454]  z_erofs_runqueue+0xf30/0x104c
[65731.260314] [T32454]  z_erofs_readahead+0x4f0/0x968
[65731.260339] [T32454]  read_pages+0x170/0xadc
[65731.260364] [T32454]  page_cache_ra_unbounded+0x874/0xf30
[65731.260388] [T32454]  page_cache_ra_order+0x24c/0x714
[65731.260411] [T32454]  filemap_fault+0xbf0/0x1a74
[65731.260437] [T32454]  __do_fault+0xd0/0x33c
[65731.260462] [T32454]  handle_mm_fault+0xf74/0x3fe0
[65731.260486] [T32454]  do_mem_abort+0x54c/0x1b34
[65731.260509] [T32454]  el0_da+0x44/0x94
[65731.260531] [T32454]  el0t_64_sync_handler+0x98/0xb4
[65731.260553] [T32454]  el0t_64_sync+0x198/0x19c
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91; https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4; https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc
CVE: CVE-2024-39475
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: savage: Handle err return when savagefb_check_var failed

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b; https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089; https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95
CVE: CVE-2024-39476
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with
small possibility, the root cause is exactly the same as commit
bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated
the problem and found out that this is caused by plugged bio can't issue
from raid5d().

Current implementation in raid5d() has a weird dependence:

1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear
   MD_SB_CHANGE_PENDING;
2) raid5d() handles IO in a deadloop, until all IO are issued;
3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other
context hold 'reconfig_mutex', and md_check_recovery() can't update
super_block, then raid5d() will waste one cpu 100% by the deadloop, until
'reconfig_mutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by
skipping issue IO if MD_SB_CHANGE_PENDING is still set after
md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'
is released. Meanwhile, the hang problem will be fixed as well.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a; https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa; https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b
CVE: CVE-2024-39477
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: do not call vma_add_reservation upon ENOMEM

sysbot reported a splat [1] on __unmap_hugepage_range().  This is because
vma_needs_reservation() can return -ENOMEM if
allocate_file_region_entries() fails to allocate the file_region struct
for the reservation.

Check for that and do not call vma_add_reservation() if that is the case,
otherwise region_abort() and region_del() will see that we do not have any
file_regions.

If we detect that vma_needs_reservation() returned -ENOMEM, we clear the
hugetlb_restore_reserve flag as if this reservation was still consumed, so
free_huge_folio() will not increment the resv count.

[1] https://lore.kernel.org/linux-mm/[PII_REDACTED][PII_REDACTED]17c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/8daf9c702ee7f825f0de8600abff764acfedea13; https://git.kernel.org/stable/c/aa998f9dcb34c28448f86e8f5490f20d5eb0eac7; https://git.kernel.org/stable/c/8daf9c702ee7f825f0de8600abff764acfedea13
CVE: CVE-2024-39478
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: starfive - Do not free stack buffer

RSA text data uses variable length buffer allocated in software stack.
Calling kfree on it causes undefined behaviour in subsequent operations.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/5944de192663f272033501dcd322b008fca72006; https://git.kernel.org/stable/c/d7f01649f4eaf1878472d3d3f480ae1e50d98f6c; https://git.kernel.org/stable/c/5944de192663f272033501dcd322b008fca72006
CVE: CVE-2024-39479
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/hwmon: Get rid of devm

When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):

Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0

and

Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0

This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.

The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.

v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
    Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)
CVSS Score: 7.8 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281; https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f; https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c[PII_REDACTED]b48a2
CVE: CVE-2024-39480
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

kdb: Fix buffer overflow during tab-complete

Currently, when the user attempts symbol completion with the Tab key, kdb
will use strncpy() to insert the completed symbol into the command buffer.
Unfortunately it passes the size of the source buffer rather than the
destination to strncpy() with predictably horrible results. Most obviously
if the command buffer is already full but cp, the cursor position, is in
the middle of the buffer, then we will write past the end of the supplied
buffer.

Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()
calls plus explicit boundary checks to make sure we have enough space
before we start moving characters around.
CVSS Score: 7.8 (HIGH)
CWE: CWE-120, CWE-121
References: https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5; https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7; https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d[PII_REDACTED]c8ddc55fa96
CVE: CVE-2024-39481
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mc: Fix graph walk in media_pipeline_start

The graph walk tries to follow all links, even if they are not between
pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.

Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK
links.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/788fd0f11e45ae8d3a8ebbd3452a6e83f92db376; https://git.kernel.org/stable/c/8a9d420149c477e7c97fbd6453704e4612bdd3fa; https://git.kernel.org/stable/c/bee9440bc0b6b3b7432f7bfde28656262a3484a2
CVE: CVE-2024-39482
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

bcache: fix variable length array abuse in btree_iter

btree_iter is used in two ways: either allocated on the stack with a
fixed size MAX_BSETS, or from a mempool with a dynamic size based on the
specific cache set. Previously, the struct had a fixed-length array of
size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized
iterators, which causes UBSAN to complain.

This patch uses the same approach as in bcachefs's sort_iter and splits
the iterator into a btree_iter with a flexible array member and a
btree_iter_stack which embeds a btree_iter as well as a fixed-length
data array.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671; https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b; https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31
CVE: CVE-2024-39483
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked

When requesting an NMI window, WARN on vNMI support being enabled if and
only if NMIs are actually masked, i.e. if the vCPU is already handling an
NMI.  KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of
view) is to inject one NMI and pend the other.  When using vNMI, KVM pends
the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the
rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).

However, if KVM can't immediately inject an NMI, e.g. because the vCPU is
in an STI shadow or is running with GIF=0, then KVM will request an NMI
window and trigger the WARN (but still function correctly).

Whether or not the GIF=0 case makes sense is debatable, as the intent of
KVM's behavior is to provide functionality that is as close to real
hardware as possible.  E.g. if two NMIs are sent in quick succession, the
probability of both NMIs arriving in an STI shadow is infinitesimally low
on real hardware, but significantly larger in a virtual environment, e.g.
if the vCPU is preempted in the STI shadow.  For GIF=0, the argument isn't
as clear cut, because the window where two NMIs can collide is much larger
in bare metal (though still small).

That said, KVM should not have divergent behavior for the GIF=0 case based
on whether or not vNMI support is enabled.  And KVM has allowed
simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400
("KVM: Fix simultaneous NMIs").  I.e. KVM's GIF=0 handling shouldn't be
modified without a *really* good reason to do so, and if KVM's behavior
were to be modified, it should be done irrespective of vNMI support.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1d87cf2eba46deaff[PII_REDACTED]f2323de9f84d1; https://git.kernel.org/stable/c/b4bd[PII_REDACTED]20ee3a91fbcba73c579669edc6; https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356
CVE: CVE-2024-39484
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: davinci: Don't strip remove function when driver is builtin

Using __exit for the remove function results in the remove callback being
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
using sysfs or hotplug), the driver is just removed without the cleanup
being performed. This results in resource leaks. Fix it by compiling in the
remove callback unconditionally.

This also fixes a W=1 modpost warning:

WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
reference: davinci_mmcsd_driver+0x10 (section: .data) ->
davinci_mmcsd_remove (section: .exit.text)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-770
References: https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584; https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3; https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e
CVE: CVE-2024-39485
Published: 2024-07-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: v4l: async: Properly re-initialise notifier entry in unregister

The notifier_entry of a notifier is not re-initialised after unregistering
the notifier. This leads to dangling pointers being left there so use
list_del_init() to return the notifier_entry an empty list.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-665
References: https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66; https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb; https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a
CVE: CVE-2024-6209
Published: 2024-07-05
Description: Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series

 v3.08.01

; MATRIX Series 

 v3.08.01 allows Attacker to access files unauthorized
CVSS Score: 10.0 (CRITICAL)
CWE: CWE-552
References: https://search.abb.com/library/Download.aspx?DocumentID=9AKK108469A7497&LanguageCode=en&DocumentPartId=&Action=Launch; https://search.abb.com/library/Download.aspx?DocumentID=9AKK108469A7497&LanguageCode=en&DocumentPartId=&Action=Launch&_ga=2.39[PII_REDACTED]5[PII_REDACTED][PII_REDACTED]70[PII_REDACTED]
CVE: CVE-2024-6298
Published: 2024-07-05
Description: Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series

 v3.08.01

; MATRIX Series 

 v3.08.01 allows Attacker to execute arbitrary code remotely
CVSS Score: 10.0 (CRITICAL)
CWE: CWE-1287
References: https://search.abb.com/library/Download.aspx?DocumentID=9AKK108469A7497&LanguageCode=en&DocumentPartId=&Action=Launch; https://search.abb.com/library/Download.aspx?DocumentID=9AKK108469A7497&LanguageCode=en&DocumentPartId=&Action=Launch&_ga=2.39[PII_REDACTED]5[PII_REDACTED][PII_REDACTED]70[PII_REDACTED]
CVE: CVE-2024-6523
Published: 2024-07-05
Description: A vulnerability was found in ZKTeco BioTime up to 9.5.2. It has been classified as problematic. Affected is an unknown function of the component system-group-add Handler. The manipulation of the argument user with the input <script>alert('XSS')</script> leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-270366 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: 3.5 (LOW)
CWE: CWE-79, CWE-79
References: https://gist.github.com/whiteman007/c8bf92b0294cd2f0cda6bfaca36f8f28; https://vuldb.com/?ctiid.270366; https://vuldb.com/?id.270366
CVE: CVE-2024-6524
Published: 2024-07-05
Description: A vulnerability was found in ShopXO up to 6.1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file extend/base/Uploader.php. The manipulation of the argument source leads to server-side request forgery. 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-270367. NOTE: The original disclosure confuses CSRF with SSRF.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-918, CWE-918
References: https://github.com/J1rrY-learn/learn/blob/main/shopxo_ssrf.md; https://vuldb.com/?ctiid.270367; https://vuldb.com/?id.270367
CVE: CVE-2024-6525
Published: 2024-07-05
Description: ** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in D-Link DAR-7000 up to 20230922. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /log/decodmail.php. The manipulation of the argument file leads to deserialization. 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-270368. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
CVSS Score: 2.7 (LOW)
CWE: CWE-502
References: https://github.com/flyyue2001/cve/blob/main/D-LINK%20-DAR-7000_rce_%20decodmail.md; https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10354; https://vuldb.com/?ctiid.270368
CVE: CVE-2024-23588
Published: 2024-07-05
Description: HCL Nomad server on Domino fails to properly handle users configured with limited Domino access resulting in a possible denial of service vulnerability.
CVSS Score: 5.3 (MEDIUM)
References: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0114193; https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0114193
CVE: CVE-2024-38346
Published: 2024-07-05
Description: The CloudStack cluster service runs on unauthenticated port (default 9090) that can be misused to run arbitrary commands on targeted hypervisors and CloudStack management server hosts. Some of these commands were found to have command injection vulnerabilities that can result in arbitrary code execution via agents on the hosts that may run as a privileged user. An attacker that can reach the cluster service on the unauthenticated port (default 9090), can exploit this to perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.

Users are recommended to restrict the network access to the cluster service port (default 9090) on a CloudStack management server host to only its peer CloudStack management server hosts. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-94
References: http://www.openwall.com/lists/oss-security/2024/07/05/1; https://cloudstack.apache.org/blog/security-release-advisory-4.19.0.2-4.18.2.1; https://lists.apache.org/thread/6l51r00csrct61plkyd3qg3fj99215d1