Total
35740 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-39673 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.8 MEDIUM |
| Vulnerability of serialisation/deserialisation mismatch in the iAware module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-39672 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 8.4 HIGH |
| Memory request logic vulnerability in the memory module. Impact: Successful exploitation of this vulnerability will affect integrity and availability. | |||||
| CVE-2024-39670 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.2 MEDIUM |
| Privilege escalation vulnerability in the account synchronisation module. Impact: Successful exploitation of this vulnerability will affect availability. | |||||
| CVE-2024-39593 | 1 Sap | 1 Landscape Management | 2026-06-17 | N/A | 6.9 MEDIUM |
| SAP Landscape Management allows an authenticated user to read confidential data disclosed by the REST Provider Definition response. Successful exploitation can cause high impact on confidentiality of the managed entities. | |||||
| CVE-2024-39580 | 1 Dell | 1 Insightiq | 2026-06-17 | N/A | 6.7 MEDIUM |
| Dell PowerScale InsightIQ, versions 5.0 through 5.1, contains an Improper Access Control vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges. | |||||
| CVE-2024-39579 | 1 Dell | 1 Powerscale Onefs | 2026-06-17 | N/A | 6.7 MEDIUM |
| Dell PowerScale OneFS versions 8.2.2.x through 9.8.0.0 contains an incorrect privilege assignment vulnerability. A local high privileged attacker could potentially exploit this vulnerability to gain root-level access. | |||||
| CVE-2024-39574 | 1 Dell | 1 Insightiq | 2026-06-17 | N/A | 6.7 MEDIUM |
| Dell PowerScale InsightIQ, version 5.1, contain an Improper Privilege Management vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Denial of service. | |||||
| CVE-2024-39557 | 1 Juniper | 1 Junos Os Evolved | 2026-06-17 | N/A | 6.5 MEDIUM |
| An Uncontrolled Resource Consumption vulnerability in the Layer 2 Address Learning Daemon (l2ald) of Juniper Networks Junos OS Evolved allows an unauthenticated, adjacent attacker to cause a memory leak, eventually exhausting all system memory, leading to a system crash and Denial of Service (DoS). Certain MAC table updates cause a small amount of memory to leak. Once memory utilization reaches its limit, the issue will result in a system crash and restart. To identify the issue, execute the CLI command: user@device> show platform application-info allocations app l2ald-agent EVL Object Allocation Statistics: Node Application Context Name Live Allocs Fails Guids re0 l2ald-agent net::juniper::rtnh::L2Rtinfo 1069096 1069302 0 1069302 re0 l2ald-agent net::juniper::rtnh::NHOpaqueTlv 114 195 0 195 This issue affects Junos OS Evolved: * All versions before 21.4R3-S8-EVO, * from 22.2-EVO before 22.2R3-S4-EVO, * from 22.3-EVO before 22.3R3-S3-EVO, * from 22.4-EVO before 22.4R3-EVO, * from 23.2-EVO before 23.2R2-EVO. | |||||
| CVE-2024-39513 | 1 Juniper | 1 Junos Os Evolved | 2026-06-17 | N/A | 5.5 MEDIUM |
| An Improper Input Validation vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved allows a local, low-privileged attacker to cause a Denial of Service (DoS). When a specific "clear" command is run, the Advanced Forwarding Toolkit manager (evo-aftmand-bt or evo-aftmand-zx) crashes and restarts. The crash impacts all traffic going through the FPCs, causing a DoS. Running the command repeatedly leads to a sustained DoS condition. This issue affects Junos OS Evolved: * All versions before 20.4R3-S9-EVO, * from 21.2-EVO before 21.2R3-S7-EVO, * from 21.3-EVO before 21.3R3-S5-EVO, * from 21.4-EVO before 21.4R3-S6-EVO, * from 22.1-EVO before 22.1R3-S4-EVO, * from 22.2-EVO before 22.2R3-S3-EVO, * from 22.3-EVO before 22.3R3-S3-EVO, * from 22.4-EVO before 22.4R3-EVO, * from 23.2-EVO before 23.2R2-EVO. | |||||
| CVE-2024-39511 | 1 Juniper | 1 Junos | 2026-06-17 | N/A | 5.5 MEDIUM |
| An Improper Input Validation vulnerability in the 802.1X Authentication (dot1x) Daemon of Juniper Networks Junos OS allows a local, low-privileged attacker with access to the CLI to cause a Denial of Service (DoS). On running a specific operational dot1x command, the dot1x daemon crashes. An attacker can cause a sustained DoS condition by running this command repeatedly. When the crash occurs, the authentication status of any 802.1x clients is cleared, and any authorized dot1x port becomes unauthorized. The client cannot re-authenticate until the dot1x daemon restarts. This issue affects Junos OS: * All versions before 20.4R3-S10; * 21.2 versions before 21.2R3-S7; * 21.4 versions before 21.4R3-S6; * 22.1 versions before 22.1R3-S5; * 22.2 versions before 22.2R3-S3; * 22.3 versions before 22.3R3-S2; * 22.4 versions before 22.4R3-S1; * 23.2 versions before 23.2R2. | |||||
| CVE-2024-39483 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| 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. | |||||
| CVE-2024-39481 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| 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. | |||||
| CVE-2024-39479 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| 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) | |||||
| CVE-2024-39469 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.1 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors The error handling in nilfs_empty_dir() when a directory folio/page read fails is incorrect, as in the old ext2 implementation, and if the folio/page cannot be read or nilfs_check_folio() fails, it will falsely determine the directory as empty and corrupt the file system. In addition, since nilfs_empty_dir() does not immediately return on a failed folio/page read, but continues to loop, this can cause a long loop with I/O if i_size of the directory's inode is also corrupted, causing the log writer thread to wait and hang, as reported by syzbot. Fix these issues by making nilfs_empty_dir() immediately return a false value (0) if it fails to get a directory folio/page. | |||||
| CVE-2024-39465 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: mgb4: Fix double debugfs remove Fixes an error where debugfs_remove_recursive() is called first on a parent directory and then again on a child which causes a kernel panic. [hverkuil: added Fixes/Cc tags] | |||||
| CVE-2024-39441 | 2 Google, Unisoc | 13 Android, S8000, T310 and 10 more | 2026-06-17 | N/A | 7.1 HIGH |
| In wifi display, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. | |||||
| CVE-2024-39435 | 2 Google, Unisoc | 14 Android, S8000, Sc7731e and 11 more | 2026-06-17 | N/A | 6.5 MEDIUM |
| In Logmanager service, there is a possible missing verification incorrect input. This could lead to local escalation of privilege with no additional execution privileges needed. | |||||
| CVE-2024-39419 | 1 Adobe | 2 Commerce, Magento | 2026-06-17 | N/A | 4.3 MEDIUM |
| Adobe Commerce versions 2.4.7-p1, 2.4.6-p6, 2.4.5-p8, 2.4.4-p9 and earlier are affected by an Improper Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and modify minor information. Exploitation of this issue does not require user interaction. | |||||
| CVE-2024-39418 | 1 Adobe | 2 Commerce, Magento | 2026-06-17 | N/A | 5.4 MEDIUM |
| Adobe Commerce versions 2.4.7-p1, 2.4.6-p6, 2.4.5-p8, 2.4.4-p9 and earlier are affected by an Improper Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures to view and edit low-sensitivity information. Exploitation of this issue does not require user interaction. | |||||
| CVE-2024-39417 | 1 Adobe | 2 Commerce, Magento | 2026-06-17 | N/A | 4.3 MEDIUM |
| Adobe Commerce versions 2.4.7-p1, 2.4.6-p6, 2.4.5-p8, 2.4.4-p9 and earlier are affected by an Improper Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and disclose minor information. Exploitation of this issue does not require user interaction. | |||||