Total
36333 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-42124 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Make qedf_execute_tmf() non-preemptible Stop calling smp_processor_id() from preemptible code in qedf_execute_tmf90. This results in BUG_ON() when running an RT kernel. [ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646 [ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf] | |||||
| CVE-2024-42119 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip finding free audio for unknown engine_id [WHY] ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it also means it is uninitialized and does not need free audio. [HOW] Skip and return NULL. This fixes 2 OVERRUN issues reported by Coverity. | |||||
| CVE-2024-42098 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| 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-42095 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: serial: 8250_omap: Implementation of Errata i2310 As per Errata i2310[0], Erroneous timeout can be triggered, if this Erroneous interrupt is not cleared then it may leads to storm of interrupts, therefore apply Errata i2310 solution. [0] https://www.ti.com/lit/pdf/sprz536 page 23 | |||||
| CVE-2024-42087 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| 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-42084 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake. | |||||
| CVE-2024-42077 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba | |||||
| CVE-2024-42039 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 4.3 MEDIUM |
| Access control vulnerability in the SystemUI module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42038 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 8.8 HIGH |
| Vulnerability of PIN enhancement failures in the screen lock module Impact: Successful exploitation of this vulnerability may affect service confidentiality, integrity, and availability. | |||||
| CVE-2024-42037 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 9.3 CRITICAL |
| Vulnerability of uncaught exceptions in the Graphics module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42036 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 2.5 LOW |
| Access permission verification vulnerability in the Notepad module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42035 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 8.4 HIGH |
| Permission control vulnerability in the App Multiplier module Impact:Successful exploitation of this vulnerability may affect functionality and confidentiality. | |||||
| CVE-2024-42034 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.6 MEDIUM |
| LaunchAnywhere vulnerability in the account module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42033 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.9 MEDIUM |
| Access control vulnerability in the security verification module mpact: Successful exploitation of this vulnerability will affect integrity and confidentiality. | |||||
| CVE-2024-42032 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 4.4 MEDIUM |
| Access permission verification vulnerability in the Contacts module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42031 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 7.5 HIGH |
| Access permission verification vulnerability in the Settings module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42030 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-17 | N/A | 6.2 MEDIUM |
| Access permission verification vulnerability in the content sharing pop-up module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42022 | 1 Veeam | 1 One | 2026-06-17 | N/A | 5.3 MEDIUM |
| An incorrect permission assignment vulnerability allows an attacker to modify product configuration files. | |||||
| CVE-2024-42021 | 1 Veeam | 1 One | 2026-06-17 | N/A | 6.5 MEDIUM |
| An improper access control vulnerability allows an attacker with valid access tokens to access saved credentials. | |||||
| CVE-2024-42006 | 1 Keyfactor | 1 Aws Orchestrator | 2026-06-17 | N/A | 7.5 HIGH |
| Keyfactor AWS Orchestrator through 2.0 allows Information Disclosure. | |||||