Total
300 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| 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 | N/A | 7.8 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-2023-27934 | 1 Apple | 1 Macos | 2025-01-29 | N/A | 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 | N/A | 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-2024-45289 | 2025-01-10 | N/A | 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. | |||||
| CVE-2024-54129 | 2024-12-05 | N/A | N/A | ||
| The NASA’s Interplanetary Overlay Network (ION) is an implementation of Delay/Disruption Tolerant Networking (DTN). A vulnerability exists in the version ION-DTN BPv7 implementation version 4.1.3 when receiving a bundle with an improper reference to the imc scheme with valid Service-Specific Part (SSP) in their Previous Node Block. The vulnerability can cause ION to become unresponsive. This vulnerability is fixed in 4.1.3s. | |||||
| CVE-2024-44947 | 1 Linux | 1 Linux Kernel | 2024-11-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter). | |||||
| CVE-2024-42078 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: initialise nfsd_info.mutex early. nfsd_info.mutex can be dereferenced by svc_pool_stats_start() immediately after the new netns is created. Currently this can trigger an oops. Move the initialisation earlier before it can possibly be dereferenced. | |||||
| CVE-2024-39485 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| 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. | |||||
| CVE-2024-39301 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/9p: fix uninit-value in p9_client_rpc() Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. | |||||
| CVE-2024-36455 | 2024-11-21 | N/A | N/A | ||
| An improper input validation allows an unauthenticated attacker to achieve remote command execution on the affected PAM system by sending a specially crafted HTTP request. | |||||
| CVE-2024-0089 | 2 Microsoft, Nvidia | 10 Windows, Cloud Gaming, Geforce and 7 more | 2024-11-21 | N/A | 7.8 HIGH |
| NVIDIA GPU Display Driver for Windows contains a vulnerability where the information from a previous client or another process could be disclosed. A successful exploit of this vulnerability might lead to code execution, information disclosure, or data tampering. | |||||
| CVE-2023-5370 | 1 Freebsd | 1 Freebsd | 2024-11-21 | N/A | 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-52452 | 1 Linux | 1 Linux Kernel | 2024-11-21 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv. | |||||
| CVE-2023-4503 | 1 Redhat | 3 Enterprise Linux, Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Expansion Pack | 2024-11-21 | N/A | 6.8 MEDIUM |
| An improper initialization vulnerability was found in Galleon. When using Galleon to provision custom EAP or EAP-XP servers, the servers are created unsecured. This issue could allow an attacker to access remote HTTP services available from the server. | |||||
| CVE-2023-49062 | 1 Facebook | 1 Katran | 2024-11-21 | N/A | 7.5 HIGH |
| Katran could disclose non-initialized kernel memory as part of an IP header. The issue was present for IPv4 encapsulation and ICMP (v4) Too Big packet generation. After a bpf_xdp_adjust_head call, Katran code didn’t initialize the Identification field for the IPv4 header, resulting in writing content of kernel memory in that field of IP header. The issue affected all Katran versions prior to commit 6a03106ac1eab39d0303662963589ecb2374c97f | |||||
| CVE-2023-45315 | 2024-11-21 | N/A | 5.5 MEDIUM | ||
| Improper initialization in some Intel(R) Power Gadget software for Windwos all versions may allow an authenticated user to potentially enable denial of service via local access. | |||||
| CVE-2023-45085 | 1 Softiron | 1 Hypercloud | 2024-11-21 | N/A | 3.2 LOW |
| An issue exists in SoftIron HyperCloud where compute nodes may come online immediately without following the correct initialization process. In this instance, workloads may be scheduled on these nodes and deploy to a failed or erroneous state, which impacts the availability of these workloads that may be deployed during this time window. This issue impacts HyperCloud versions from 2.0.0 to before 2.0.3. | |||||
| CVE-2023-40349 | 1 Jenkins | 1 Gogs | 2024-11-21 | N/A | 5.3 MEDIUM |
| Jenkins Gogs Plugin 1.0.15 and earlier improperly initializes an option to secure its webhook endpoint, allowing unauthenticated attackers to trigger builds of jobs. | |||||
| CVE-2023-3242 | 1 Br-automation | 1 Automation Runtime | 2024-11-21 | N/A | 8.6 HIGH |
| Improper initialization implementation in Portmapper used in B&R Industrial Automation Automation Runtime <G4.93 allows unauthenticated network-based attackers to cause permanent denial-of-service conditions. | |||||
| CVE-2023-37479 | 1 Openenclave | 1 Openenclave | 2024-11-21 | N/A | 5.3 MEDIUM |
| Open Enclave is a hardware-agnostic open source library for developing applications that utilize Hardware-based Trusted Execution Environments, also known as Enclaves. There are two issues that are mitigated in version 0.19.3. First, Open Enclave SDK does not properly sanitize the `MXCSR` register on enclave entry. This makes applications vulnerable to MXCSR Configuration Dependent Timing (MCDT) attacks, where incorrect `MXCSR` values can impact instruction retirement by at most one cycle, depending on the (secret) data operand value. Please find more details in the guidance from Intel in the references. Second, Open Enclave SDK does not sanitize x86's alignment check flag `RFLAGS.AC` on enclave entry. This opens up the possibility for a side-channel attacker to be notified for every unaligned memory access performed by the enclave. The issue has been addressed in version 0.19.3 and the current master branch. Users will need to recompile their applications against the patched libraries to be protected from this vulnerability. There are no known workarounds for this vulnerability. | |||||