Total
412 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-5370 | 1 Freebsd | 1 Freebsd | 2025-02-13 | 5.5 Medium |
| On CPU 0 the check for the SMCCC workaround is called before SMCCC support has been initialized. This resulted in no speculative execution workarounds being installed on CPU 0. | ||||
| CVE-2023-31926 | 1 Broadcom | 1 Brocade Fabric Operating System | 2025-02-13 | 7.1 High |
| System files could be overwritten using the less command in Brocade Fabric OS before Brocade Fabric OS v9.1.1c and v9.2.0. | ||||
| CVE-2022-38083 | 1 Intel | 474 Core I5-7640x, Core I5-7640x Firmware, Core I7-3820 and 471 more | 2025-02-13 | 6.1 Medium |
| Improper initialization in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access. | ||||
| CVE-2024-31157 | 2025-02-13 | 5.3 Medium | ||
| Improper initialization in UEFI firmware OutOfBandXML module in some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access. | ||||
| CVE-2022-32579 | 1 Intel | 4 Lapbc510, Lapbc510 Firmware, Lapbc710 and 1 more | 2025-02-10 | 6.9 Medium |
| Improper initialization in the firmware for some Intel(R) NUC Laptop Kits before version BC0076 may allow a privileged user to potentially enable escalation of privilege via physical access. | ||||
| CVE-2023-25010 | 1 Autodesk | 1 Maya Usd | 2025-02-06 | 7.8 High |
| A malicious actor may convince a victim to open a malicious USD file that may trigger an uninitialized variable which may result in code execution. | ||||
| CVE-2023-27325 | 1 Parallels | 1 Parallels Desktop | 2025-02-05 | 7.8 High |
| Parallels Desktop Updater Improper Initialization Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop. An attacker must first obtain the ability to execute low-privileged code on the target host system in order to exploit this vulnerability. The specific flaw exists within the Updater service. The issue results from the lack of proper initialization of environment variables. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of root. . Was ZDI-CAN-18253. | ||||
| CVE-2022-37334 | 1 Intel | 22 Nuc 11 Pro Board Nuc11tnbi30z, Nuc 11 Pro Board Nuc11tnbi30z Firmware, Nuc 11 Pro Board Nuc11tnbi50z and 19 more | 2025-02-05 | 7 High |
| Improper initialization in BIOS firmware for some Intel(R) NUC 11 Pro Kits and Intel(R) NUC 11 Pro Boards before version TNTGL357.0064 may allow an authenticated user to potentially enable escalation of privilege via local access. | ||||
| CVE-2022-0847 | 7 Fedoraproject, Linux, Netapp and 4 more | 42 Fedora, Linux Kernel, H300e and 39 more | 2025-02-04 | 7.8 High |
| A flaw was found in the way the "flags" member of the new pipe buffer structure was lacking proper initialization in copy_page_to_iter_pipe and push_pipe functions in the Linux kernel and could thus contain stale values. An unprivileged local user could use this flaw to write to pages in the page cache backed by read only files and as such escalate their privileges on the system. | ||||
| CVE-2021-47462 | 1 Linux | 1 Linux Kernel | 2025-02-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() syzbot reported access to unitialized memory in mbind() [1] Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes") This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in do_set_mempolicy() This patch moves the check in sanitize_mpol_flags() so that it is also used by mbind() [1] BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_alloc_node mm/slub.c:3221 [inline] slab_alloc mm/slub.c:3230 [inline] kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235 mpol_new mm/mempolicy.c:293 [inline] do_mbind+0x912/0x15f0 mm/mempolicy.c:1289 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae ===================================================== Kernel panic - not syncing: panic_on_kmsan set ... CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G B 5.15.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106 dump_stack+0x25/0x28 lib/dump_stack.c:113 panic+0x44f/0xdeb kernel/panic.c:232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae | ||||
| CVE-2023-27934 | 1 Apple | 1 Macos | 2025-01-29 | 8.8 High |
| A memory initialization issue was addressed. This issue is fixed in macOS Ventura 13.3, macOS Monterey 12.6.4. A remote attacker may be able to cause unexpected app termination or arbitrary code execution. | ||||
| CVE-2024-22064 | 1 Zte | 1 Zxun-epdg | 2025-01-28 | 8.3 High |
| ZTE ZXUN-ePDG product, which serves as the network node of the VoWifi system, under by default configuration, uses a set of non-unique cryptographic keys during establishing a secure connection(IKE) with the mobile devices connecting over the internet . If the set of keys are leaked or cracked, the user session informations using the keys may be leaked. | ||||
| CVE-2022-32231 | 1 Intel | 362 Xeon Bronze 3104, Xeon Bronze 3104 Firmware, Xeon Bronze 3106 and 359 more | 2025-01-27 | 7.5 High |
| Improper initialization in the BIOS firmware for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. | ||||
| CVE-2022-30704 | 1 Intel | 934 Celeron 1000m, Celeron 1000m Firmware, Celeron 1005m and 931 more | 2025-01-27 | 7.2 High |
| Improper initialization in the Intel(R) TXT SINIT ACM for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access. | ||||
| CVE-2022-34153 | 1 Intel | 1 Battery Life Diagnostic Tool | 2025-01-27 | 8.2 High |
| Improper initialization in the Intel(R) Battery Life Diagnostic Tool software before version 2.2.0 may allow an authenticated user to potentially enable escalation of privilege via local access. | ||||
| CVE-2022-31477 | 1 Intel | 70 Cm11ebc4w, Cm11ebc4w Firmware, Cm11ebi38w and 67 more | 2025-01-27 | 4 Medium |
| Improper initialization for some Intel(R) NUC BIOS firmware may allow a privileged user to potentially enable information disclosure via local access. | ||||
| CVE-2024-44949 | 1 Linux | 1 Linux Kernel | 2025-01-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. | ||||
| CVE-2024-57804 | 2025-01-21 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs The driver, through the SAS transport, exposes a sysfs interface to enable/disable PHYs in a controller/expander setup. When multiple PHYs are disabled and enabled in rapid succession, the persistent and current config pages related to SAS IO unit/SAS Expander pages could get corrupted. Use separate memory for each config request. | ||||
| CVE-2024-56641 | 2025-01-20 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: net/smc: initialize close_work early to avoid warning We encountered a warning that close_work was canceled before initialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30 This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func). __smc_lgr_terminate | smc_connect_{rdma|ism} ------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_conn for conn in lgr->conns_all | \- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work) So fix this by initializing close_work before establishing the connection. | ||||
| CVE-2024-45289 | 1 Freebsd | 1 Freebsd | 2025-01-10 | 7.5 High |
| The fetch(3) library uses environment variables for passing certain information, including the revocation file pathname. The environment variable name used by fetch(1) to pass the filename to the library was incorrect, in effect ignoring the option. Fetch would still connect to a host presenting a certificate included in the revocation file passed to the --crl option. | ||||