Total
258583 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-45249 | 1 Acronis | 1 Cyber Infrastructure | 2024-07-30 | N/A | 9.8 CRITICAL |
| Remote command execution due to use of default passwords. The following products are affected: Acronis Cyber Infrastructure (ACI) before build 5.0.1-61, Acronis Cyber Infrastructure (ACI) before build 5.1.1-71, Acronis Cyber Infrastructure (ACI) before build 5.2.1-69, Acronis Cyber Infrastructure (ACI) before build 5.3.1-53, Acronis Cyber Infrastructure (ACI) before build 5.4.4-132. | |||||
| CVE-2024-38909 | 2024-07-30 | N/A | N/A | ||
| Studio 42 elFinder 2.1.64 is vulnerable to Incorrect Access Control. Copying files with an unauthorized extension between server directories allows an arbitrary attacker to expose secrets, perform RCE, etc. | |||||
| CVE-2024-23091 | 2024-07-30 | N/A | N/A | ||
| Weak password hashing using MD5 in funzioni.php in HotelDruid before 1.32 allows an attacker to obtain plaintext passwords from hash values. | |||||
| CVE-2024-28806 | 2024-07-30 | N/A | N/A | ||
| An issue was discovered in Italtel i-MCS NFV 12.1.0-20211215. Remote unauthenticated attackers can upload files at an arbitrary path. | |||||
| CVE-2024-42098 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: crypto: ecdh - explicitly zeroize private_key private_key is overwritten with the key parameter passed in by the caller (if present), or alternatively a newly generated private key. However, it is possible that the caller provides a key (or the newly generated key) which is shorter than the previous key. In that scenario, some key material from the previous key would not be overwritten. The easiest solution is to explicitly zeroize the entire private_key array first. Note that this patch slightly changes the behavior of this function: previously, if the ecc_gen_privkey failed, the old private_key would remain. Now, the private_key is always zeroized. This behavior is consistent with the case where params.key is set and ecc_is_key_valid fails. | |||||
| CVE-2024-42087 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep The ilitek-ili9881c controls the reset GPIO using the non-sleeping gpiod_set_value() function. This complains loudly when the GPIO controller needs to sleep. As the caller can sleep, use gpiod_set_value_cansleep() to fix the issue. | |||||
| CVE-2024-42088 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link Commit e70b8dd26711 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link") removed the codec entry for the ETDM1_OUT_BE dai link entirely instead of replacing it with COMP_EMPTY(). This worked by accident as the remaining COMP_EMPTY() platform entry became the codec entry, and the platform entry became completely empty, effectively the same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything for platform entries. This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe() in sound/soc/mediatek/common/mtk-soundcard-driver.c: for_each_card_prelinks(card, i, dai_link) { if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF"))) dai_link->platforms->of_node = adsp_node; else if (!dai_link->platforms->name && !dai_link->platforms->of_node) dai_link->platforms->of_node = platform_node; } where the code expects the platforms array to have space for at least one entry. Add an COMP_EMPTY() entry so that dai_link->platforms has space. | |||||
| CVE-2024-28804 | 2024-07-30 | N/A | N/A | ||
| An issue was discovered in Italtel i-MCS NFV 12.1.0-20211215. Stored Cross-site scripting (XSS) can occur via POST. | |||||
| CVE-2024-6727 | 2024-07-30 | N/A | 5.4 MEDIUM | ||
| A flaw in versions of Delphix Data Control Tower (DCT) prior to 19.0.0 results in broken authentication through the enable-scale-testing functionality of the application. | |||||
| CVE-2024-42093 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | |||||
| CVE-2023-42918 | 2024-07-30 | N/A | N/A | ||
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sonoma 14. A sandboxed process may be able to circumvent sandbox restrictions. | |||||
| CVE-2024-42097 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ALSA: emux: improve patch ioctl data validation In load_data(), make the validation of and skipping over the main info block match that in load_guspatch(). In load_guspatch(), add checking that the specified patch length matches the actually supplied data, like load_data() already did. | |||||
| CVE-2023-42948 | 2024-07-30 | N/A | N/A | ||
| This issue was addressed through improved state management. This issue is fixed in macOS Sonoma 14. A Wi-Fi password may not be deleted when activating a Mac in macOS Recovery. | |||||
| CVE-2024-42094 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | |||||
| CVE-2024-6620 | 2024-07-30 | N/A | 3.5 LOW | ||
| Honeywell PC42t, PC42tp, and PC42d Printers, T10.19.020016 to T10.20.060398, contain a cross-site scripting vulnerability. A(n) attacker could potentially inject malicious code which may lead to information disclosure, session theft, or client-side request forgery. Honeywell recommends updating to the most recent version of this firmware, PC42 Printer Firmware Version 20.6 T10.20.060398. | |||||
| CVE-2024-42085 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume. | |||||
| CVE-2024-28805 | 2024-07-30 | N/A | N/A | ||
| An issue was discovered in Italtel i-MCS NFV 12.1.0-20211215. There is Incorrect Access Control. | |||||
| CVE-2024-37859 | 2024-07-30 | N/A | N/A | ||
| Cross Site Scripting vulnerability in Lost and Found Information System 1.0 allows a remote attacker to escalate privileges via the page parameter to php-lfis/admin/index.php. | |||||
| CVE-2024-42096 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: x86: stop playing stack games in profile_pc() The 'profile_pc()' function is used for timer-based profiling, which isn't really all that relevant any more to begin with, but it also ends up making assumptions based on the stack layout that aren't necessarily valid. Basically, the code tries to account the time spent in spinlocks to the caller rather than the spinlock, and while I support that as a concept, it's not worth the code complexity or the KASAN warnings when no serious profiling is done using timers anyway these days. And the code really does depend on stack layout that is only true in the simplest of cases. We've lost the comment at some point (I think when the 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF. which explains why it just blindly loads a word or two straight off the stack pointer and then takes a minimal look at the values to just check if they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addresses but that basic stack layout assumption assumes that there isn't any lock debugging etc going on that would complicate the code and cause a stack frame. It causes KASAN unhappiness reported for years by syzkaller [1] and others [2]. With no real practical reason for this any more, just remove the code. Just for historical interest, here's some background commits relating to this code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64") and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc") but the basics of this thing actually goes back to before the git tree. | |||||
| CVE-2024-42089 | 2024-07-30 | N/A | N/A | ||
| In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. | |||||