Total
893 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-76042 | 1 Google | 1 Chrome | 2026-08-21 | N/A | 3.1 LOW |
| Use of uninitialized resource in GPU in Google Chrome prior to 151.0.7922.169 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-52989 | 1 Linux | 1 Linux Kernel | 2026-08-21 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers. | |||||
| CVE-2026-16868 | 1 Ibm | 1 I | 2026-08-17 | N/A | 8.1 HIGH |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to the use of uninitialized memory during ASN.1 length processing. | |||||
| CVE-2026-62740 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-08-16 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Windows Imaging Component allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-62709 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-08-16 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Windows GDI+ allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-59137 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-08-16 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Windows Event Logging Service allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-59136 | 1 Microsoft | 13 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 10 more | 2026-08-16 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Microsoft COM for Windows allows an authorized attacker to disclose information locally. | |||||
| CVE-2026-70317 | 1 Microsoft | 6 365 Apps, Microsoft 365, Office 2016 and 3 more | 2026-08-14 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Microsoft Office allows an unauthorized attacker to disclose information locally. | |||||
| CVE-2026-68799 | 1 Microsoft | 6 365 Apps, Excel, Microsoft 365 and 3 more | 2026-08-13 | N/A | 5.5 MEDIUM |
| Use of uninitialized resource in Microsoft Office Excel allows an unauthorized attacker to disclose information locally. | |||||
| CVE-2026-64130 | 1 Linux | 1 Linux Kernel | 2026-08-13 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free __GFP_ZEROTAGS semantics are currently a bit weird, but effectively this flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN. If we run with init_on_free, we will zero out pages during __free_pages_prepare(), to skip zeroing on the allocation path. However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will consequently not only skip clearing page content, but also skip clearing tag memory. Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that will get mapped to user space through set_pte_at() later: set_pte_at() and friends will detect that the tags have not been initialized yet (PG_mte_tagged not set), and initialize them. However, for the huge zero folio, which will be mapped through a PMD marked as special, this initialization will not be performed, ending up exposing whatever tags were still set for the pages. The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state that allocation tags are set to 0 when a page is first mapped to user space. That no longer holds with the huge zero folio when init_on_free is enabled. Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to tag_clear_highpages() whether we want to also clear page content. Invert the meaning of the tag_clear_highpages() return value to have clearer semantics. Reproduced with the huge zero folio by modifying the check_buffer_fill arm64/mte selftest to use a 2 MiB area, after making sure that pages have a non-0 tag set when freeing (note that, during boot, we will not actually initialize tags, but only set KASAN_TAG_KERNEL in the page flags). $ ./check_buffer_fill 1..20 ... not ok 17 Check initial tags with private mapping, sync error mode and mmap memory not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory ... This code needs more cleanups; we'll tackle that next, like decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN. [akpm@linux-foundation.org: s/__GPF_ZERO/__GFP_ZERO/, per David] | |||||
| CVE-2022-49132 | 1 Linux | 1 Linux Kernel | 2026-08-13 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ath11k: pci: fix crash on suspend if board file is not found Mario reported that the kernel was crashing on suspend if ath11k was not able to find a board file: [ 473.693286] PM: Suspending system (s2idle) [ 473.693291] printk: Suspending console(s) (use no_console_suspend to debug) [ 474.407787] BUG: unable to handle page fault for address: 0000000000002070 [ 474.407791] #PF: supervisor read access in kernel mode [ 474.407794] #PF: error_code(0x0000) - not-present page [ 474.407798] PGD 0 P4D 0 [ 474.407801] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 474.407805] CPU: 2 PID: 2350 Comm: kworker/u32:14 Tainted: G W 5.16.0 #248 [...] [ 474.407868] Call Trace: [ 474.407870] <TASK> [ 474.407874] ? _raw_spin_lock_irqsave+0x2a/0x60 [ 474.407882] ? lock_timer_base+0x72/0xa0 [ 474.407889] ? _raw_spin_unlock_irqrestore+0x29/0x3d [ 474.407892] ? try_to_del_timer_sync+0x54/0x80 [ 474.407896] ath11k_dp_rx_pktlog_stop+0x49/0xc0 [ath11k] [ 474.407912] ath11k_core_suspend+0x34/0x130 [ath11k] [ 474.407923] ath11k_pci_pm_suspend+0x1b/0x50 [ath11k_pci] [ 474.407928] pci_pm_suspend+0x7e/0x170 [ 474.407935] ? pci_pm_freeze+0xc0/0xc0 [ 474.407939] dpm_run_callback+0x4e/0x150 [ 474.407947] __device_suspend+0x148/0x4c0 [ 474.407951] async_suspend+0x20/0x90 dmesg-efi-164255130401001: Oops#1 Part1 [ 474.407955] async_run_entry_fn+0x33/0x120 [ 474.407959] process_one_work+0x220/0x3f0 [ 474.407966] worker_thread+0x4a/0x3d0 [ 474.407971] kthread+0x17a/0x1a0 [ 474.407975] ? process_one_work+0x3f0/0x3f0 [ 474.407979] ? set_kthread_struct+0x40/0x40 [ 474.407983] ret_from_fork+0x22/0x30 [ 474.407991] </TASK> The issue here is that board file loading happens after ath11k_pci_probe() succesfully returns (ath11k initialisation happends asynchronously) and the suspend handler is still enabled, of course failing as ath11k is not properly initialised. Fix this by checking ATH11K_FLAG_QMI_FAIL during both suspend and resume. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 | |||||
| CVE-2026-64220 | 1 Linux | 1 Linux Kernel | 2026-08-11 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: device property: set fwnode->secondary to NULL in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. | |||||
| CVE-2026-60005 | 1 F5 | 6 Nginx Gateway Fabric, Nginx Ingress Controller, Nginx Instance Manager and 3 more | 2026-08-11 | N/A | 8.2 HIGH |
| NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_slice_module module. When the slice directive and unnamed regex captures are configured or when a background cache update happens, unauthenticated attackers can send requests that may cause uninitialized memory access in the NGINX worker process, leading to limited disclosure of memory or a restart. Impact: This vulnerability may allow remote, unauthenticated attackers to have limited control to disclose memory contents or restart the NGINX worker process. There is no control plane exposure; this is a data plane issue only. Note: The ngx_http_slice_module module is not enabled by default; it's enabled with the --with-http_slice_module configuration parameter. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | |||||
| CVE-2024-38260 | 1 Microsoft | 6 Windows Server 2008, Windows Server 2012, Windows Server 2016 and 3 more | 2026-08-10 | N/A | 8.8 HIGH |
| Windows Remote Desktop Licensing Service Remote Code Execution Vulnerability | |||||
| CVE-2024-38257 | 1 Microsoft | 11 Windows 10 1607, Windows 10 1809, Windows 10 21h1 and 8 more | 2026-08-10 | N/A | 7.5 HIGH |
| Microsoft AllJoyn API Information Disclosure Vulnerability | |||||
| CVE-2024-38256 | 1 Microsoft | 9 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 6 more | 2026-08-10 | N/A | 5.5 MEDIUM |
| Windows Kernel-Mode Driver Information Disclosure Vulnerability | |||||
| CVE-2024-38254 | 1 Microsoft | 13 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 10 more | 2026-08-10 | N/A | 5.5 MEDIUM |
| Windows Authentication Information Disclosure Vulnerability | |||||
| CVE-2023-36913 | 1 Microsoft | 12 Windows 10, Windows 10 1607, Windows 10 1809 and 9 more | 2026-08-10 | N/A | 6.5 MEDIUM |
| Microsoft Message Queuing Information Disclosure Vulnerability | |||||
| CVE-2026-66038 | 1 Ffmpeg | 1 Ffmpeg | 2026-08-07 | N/A | 6.5 MEDIUM |
| FFmpeg through 8.1.2, fixed in commit 8670835, contains an information disclosure vulnerability in the LCL/ZLIB video decoder that allows attackers to expose uninitialized heap memory by supplying a valid zlib stream that inflates to fewer bytes than the expected frame size. The zlib_decomp() function in lcldec.c treats short decompression as non-fatal and continues to the RGB24 conversion path, which copies a full frame's worth of rows from the allocation buffer using original frame dimensions, causing uninitialized heap contents including pointer-derived allocator bytes to be copied into the attacker-observable AVFrame output and potentially defeating ASLR in long-lived media processing services. | |||||
| CVE-2024-57997 | 1 Linux | 1 Linux Kernel | 2026-08-04 | N/A | 8.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix channel survey memory allocation size KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel. | |||||