Total
446 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-36022 | 1 Redhat | 1 Enterprise Linux | 2024-11-05 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Init zone device and drm client after mode-1 reset on reload In passthrough environment, when amdgpu is reloaded after unload, mode-1 is triggered after initializing the necessary IPs, That init does not include KFD, and KFD init waits until the reset is completed. KFD init is called in the reset handler, but in this case, the zone device and drm client is not initialized, causing app to create kernel panic. v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create. As the previous version has the potential of creating DRM client twice. v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA before SDMA init. Adding the condition to in drm client creation, on top of v1, to guard against drm client creation call multiple times. | ||||
| CVE-2024-27022 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2024-11-05 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fork: defer linking file vma until vma is fully initialized Thorvald reported a WARNING [1]. And the root cause is below race: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after -- Child vma is visible through i_mmap tree. i_mmap_unlock_write(mapping); hugetlb_dup_vma_private -- Clear vma_lock outside i_mmap_rwsem! i_mmap_lock_write(mapping); hugetlb_vmdelete_list vma_interval_tree_foreach hugetlb_vma_trylock_write -- Vma_lock is cleared. tmp->vm_ops->open -- Alloc new vma_lock outside i_mmap_rwsem! hugetlb_vma_unlock_write -- Vma_lock is assigned!!! i_mmap_unlock_write(mapping); hugetlb_dup_vma_private() and hugetlb_vm_op_open() are called outside i_mmap_rwsem lock while vma lock can be used in the same time. Fix this by deferring linking file vma until vma is fully initialized. Those vmas should be initialized first before they can be used. | ||||
| CVE-2022-48949 | 1 Linux | 1 Linux Kernel | 2024-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. | ||||
| CVE-2022-48864 | 1 Linux | 1 Linux Kernel | 2024-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command request from the driver, presently there is no validation against the number of queue pairs to configure, or even if multiqueue had been negotiated or not is unverified. This may lead to kernel panic due to uninitialized resource for the queues were there any bogus request sent down by untrusted driver. Tie up the loose ends there. | ||||
| CVE-2022-48855 | 1 Linux | 1 Linux Kernel | 2024-11-04 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: sctp: fix kernel-infoleak for SCTP sockets syzbot reported a kernel infoleak [1] of 4 bytes. After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill() Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 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_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 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 Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0 CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | ||||
| CVE-2022-48747 | 1 Redhat | 1 Enterprise Linux | 2024-11-04 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. | ||||
| CVE-2022-48654 | 1 Linux | 1 Linux Kernel | 2024-11-04 | 5.3 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace. | ||||
| CVE-2021-47597 | 1 Linux | 1 Linux Kernel | 2024-11-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: inet_diag: fix kernel-infoleak for UDP sockets KMSAN reported a kernel-infoleak [1], that can exploited by unpriv users. After analysis it turned out UDP was not initializing r->idiag_expires. Other users of inet_sk_diag_fill() might make the same mistake in the future, so fix this in inet_sk_diag_fill(). [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:156 [inline] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [inline] new_sync_read fs/read_write.c:400 [inline] vfs_read+0x1631/0x1980 fs/read_write.c:481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [inline] __se_sys_read fs/read_write.c:627 [inline] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 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_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] sock_write_iter+0x594/0x690 net/socket.c:1057 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x63f/0xe30 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 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 Bytes 68-71 of 312 are uninitialized Memory access of size 312 starts at ffff88812ab54000 Data copied to user address 0000000020001440 CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | ||||
| CVE-2024-8896 | 1 Autodesk | 10 Autocad, Autocad Advance Steel, Autocad Architecture and 7 more | 2024-11-01 | 7.8 High |
| A maliciously crafted DXF file when parsed in acdb25.dll through Autodesk AutoCAD can force to access a variable prior to initialization. A malicious actor can leverage this vulnerability to cause a crash, write sensitive data, or execute arbitrary code in the context of the current process. | ||||
| CVE-2024-3862 | 2024-10-30 | 5.3 Medium | ||
| The MarkStack assignment operator, part of the JavaScript engine, could access uninitialized memory if it were used in a self-assignment. This vulnerability affects Firefox < 125. | ||||
| CVE-2023-36836 | 1 Juniper | 2 Junos, Junos Os Evolved | 2024-10-22 | 4.7 Medium |
| A Use of an Uninitialized Resource vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a local, authenticated attacker with low privileges to cause a Denial of Service (DoS). On all Junos OS and Junos OS Evolved platforms, in a Multicast only Fast Reroute (MoFRR) scenario, the rpd process can crash when a a specific low privileged CLI command is executed. The rpd crash will impact all routing protocols until the process has automatically been restarted. As the operational state which makes this issue exploitable is outside the attackers control, this issue is considered difficult to exploit. Continued execution of this command will lead to a sustained DoS. This issue affects: Juniper Networks Junos OS 19.4 version 19.4R3-S5 and later versions prior to 19.4R3-S9; 20.1 version 20.1R2 and later versions; 20.2 versions prior to 20.2R3-S7; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3-S1; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R1-S2, 22.1R2; 22.2 versions prior to 22.2R2. Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S6-EVO; 21.1-EVO version 21.1R1-EVO and later versions; 21.2-EVO version 21.2R1-EVO and later versions; 21.3-EVO versions prior to 21.3R3-S1-EVO; 21.4-EVO versions prior to 21.4R3-EVO; 22.1-EVO versions prior to 22.1R1-S2-EVO, 22.1R2-EVO; 22.2-EVO versions prior to 22.2R2-EVO. | ||||
| CVE-2009-1529 | 1 Microsoft | 7 Ie, Internet Explorer, Windows 2000 and 4 more | 2024-10-21 | 8.1 High |
| Microsoft Internet Explorer 7 for Windows XP SP2 and SP3; 7 for Server 2003 SP2; 7 for Vista Gold, SP1, and SP2; and 7 for Server 2008 SP2 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by calling the setCapture method on a collection of crafted objects, aka "Uninitialized Memory Corruption Vulnerability." | ||||
| CVE-2012-1891 | 1 Microsoft | 7 Data Access Components, Windows 7, Windows Data Access Components and 4 more | 2024-10-17 | 9.8 Critical |
| Heap-based buffer overflow in Microsoft Data Access Components (MDAC) 2.8 SP1 and SP2 and Windows Data Access Components (WDAC) 6.0 allows remote attackers to execute arbitrary code via crafted XML data that triggers access to an uninitialized object in memory, aka "ADO Cachesize Heap Overflow RCE Vulnerability." | ||||
| CVE-2024-47966 | 2 Delta Electronics, Deltaww | 2 Cncsoft-g2, Cncsoft-g2 | 2024-10-17 | 7.8 High |
| Delta Electronics CNCSoft-G2 lacks proper initialization of memory prior to accessing it. An attacker can manipulate users to visit a malicious page or file to leverage this vulnerability to execute code in the context of the current process. | ||||
| CVE-2024-38122 | 1 Microsoft | 25 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 22 more | 2024-10-16 | 5.5 Medium |
| Microsoft Local Security Authority (LSA) Server Information Disclosure Vulnerability | ||||
| CVE-2024-38118 | 1 Microsoft | 25 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 22 more | 2024-10-16 | 5.5 Medium |
| Microsoft Local Security Authority (LSA) Server Information Disclosure Vulnerability | ||||
| CVE-2023-3488 | 1 Silabs | 1 Gecko Software Development Kit | 2024-10-11 | 3.8 Low |
| Uninitialized buffer in GBL parser in Silicon Labs GSDK v4.3.0 and earlier allows attacker to leak data from Secure stack via malformed GBL file. | ||||
| CVE-2023-21276 | 1 Google | 1 Android | 2024-10-09 | 5.5 Medium |
| In writeToParcel of CursorWindow.cpp, there is a possible information disclosure due to uninitialized data. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2023-21233 | 1 Google | 1 Android | 2024-10-09 | 7.5 High |
| In multiple locations of avrc, there is a possible leak of heap data due to uninitialized data. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. | ||||
| CVE-2024-26220 | 1 Microsoft | 12 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 9 more | 2024-10-09 | 5 Medium |
| Windows Mobile Hotspot Information Disclosure Vulnerability | ||||