Total
35471 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-43502 | 1 Microsoft | 6 Windows 10 1809, Windows 10 21h2, Windows 10 21h2 and 3 more | 2026-06-09 | 7.1 High |
| Windows Kernel Elevation of Privilege Vulnerability | ||||
| CVE-2024-38229 | 4 Apple, Linux, Microsoft and 1 more | 7 Macos, Linux Kernel, .net and 4 more | 2026-06-09 | 8.1 High |
| .NET and Visual Studio Remote Code Execution Vulnerability | ||||
| CVE-2024-43480 | 2 Linux, Microsoft | 2 Linux Kernel, Azure Service Fabric | 2026-06-09 | 6.6 Medium |
| Azure Service Fabric for Linux Remote Code Execution Vulnerability | ||||
| CVE-2024-38261 | 1 Microsoft | 10 Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 Sp2 and 7 more | 2026-06-09 | 7.8 High |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | ||||
| CVE-2020-17103 | 1 Microsoft | 9 Windows 10, Windows 10 1809, Windows 11 23h2 and 6 more | 2026-06-09 | 7 High |
| Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability | ||||
| CVE-2026-46273 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 8.6 High |
| In the Linux kernel, the following vulnerability has been resolved: ibmveth: Disable GSO for packets with small MSS Some physical adapters on Power systems do not support segmentation offload when the MSS is less than 224 bytes. Attempting to send such packets causes the adapter to freeze, stopping all traffic until manually reset. Implement ndo_features_check to disable GSO for packets with small MSS values. The network stack will perform software segmentation instead. The 224-byte minimum matches ibmvnic commit <f10b09ef687f> ("ibmvnic: Enforce stronger sanity checks on GSO packets") which uses the same physical adapters in SEA configurations. The issue occurs specifically when the hardware attempts to perform segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets (gso_segs == 1) do not trigger the problematic LSO code path and are transmitted normally without segmentation. Add an ndo_features_check callback to disable GSO when MSS < 224 bytes. Also call vlan_features_check() to ensure proper handling of VLAN packets, particularly QinQ (802.1ad) configurations where the hardware parser may not support certain offload features. Validated using iptables to force small MSS values. Without the fix, the adapter freezes. With the fix, packets are segmented in software and transmission succeeds. Comprehensive regression testing completedd (MSS tests, performance, stability). | ||||
| CVE-2026-43331 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/kexec: Disable KCOV instrumentation after load_segments() The load_segments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins crashing the kernel in an endless loop. To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel: $ kexec -l /boot/otherKernel $ kexec -e The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC and CONFIG_KCOV to be enabled simultaneously. Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc()) is also undesirable as it would introduce an extra performance overhead. Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machine_kexec_64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered. The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there. [ bp: Space out comment for better readability. ] | ||||
| CVE-2026-43219 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: cpsw_new: Fix potential unregister of netdev that has not been registered yet If an error occurs during register_netdev() for the first MAC in cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL, cpsw->slaves[1].ndev would remain unchanged. This could later cause cpsw_unregister_ports() to attempt unregistering the second MAC. To address this, add a check for ndev->reg_state before calling unregister_netdev(). With this change, setting cpsw->slaves[i].ndev to NULL becomes unnecessary and can be removed accordingly. | ||||
| CVE-2026-31709 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs. Factor the DACL structural checks into validate_dacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parse_dacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL. | ||||
| CVE-2026-23346 | 1 Linux | 1 Linux Kernel | 2026-06-09 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64: io: Extract user memory type in ioremap_prot() The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN: | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | __memcpy_fromio+0x80/0xf8 | generic_access_phys+0x20c/0x2b8 | __access_remote_vm+0x46c/0x5b8 | access_remote_vm+0x18/0x30 | environ_read+0x238/0x3e8 | vfs_read+0xe4/0x2b0 | ksys_read+0xcc/0x178 | __arm64_sys_read+0x4c/0x68 Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot(). | ||||
| CVE-2025-66329 | 1 Huawei | 2 Emui, Harmonyos | 2026-06-09 | 4 Medium |
| Permission control vulnerability in the window management module. Impact: Successful exploitation of this vulnerability may affect availability. | ||||
| CVE-2026-11022 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-08 | 6.5 Medium |
| Insufficient validation of untrusted input in DevTools in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-10996 | 1 Google | 1 Chrome | 2026-06-08 | 6.5 Medium |
| Inappropriate implementation in Workers in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-10942 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-06-08 | 7.8 High |
| Inappropriate implementation in UI in Google Chrome on Windows prior to 149.0.7827.53 allowed a local attacker to perform privilege escalation via a malicious file. (Chromium security severity: High) | ||||
| CVE-2026-46579 | 1 Redhat | 3 Openshift, Openshift Container Platform, Openshift Router | 2026-06-08 | 7.4 High |
| A flaw was found in the OpenShift Router. When a Route has `insecureEdgeTerminationPolicy` set to Allow, the HTTP frontend does not remove `X-SSL-Client-*` headers from incoming requests. This allows an unauthenticated attacker to send plain HTTP requests with crafted `X-SSL-Client-*` headers. As a result, backends relying on these headers for mutual TLS (Transport Layer Security) authentication can be bypassed, enabling the attacker to impersonate client certificate identities. | ||||
| CVE-2026-11027 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-08 | 6.5 Medium |
| Insufficient validation of untrusted input in Glic in Google Chrome prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-11031 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-06-08 | 4.3 Medium |
| Insufficient validation of untrusted input in Password Manager in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to perform UI spoofing via malicious network traffic. (Chromium security severity: Medium) | ||||
| CVE-2026-11035 | 1 Google | 2 Android, Chrome | 2026-06-08 | 7.3 High |
| Inappropriate implementation in Custom Tabs in Google Chrome on Android prior to 149.0.7827.53 allowed a local attacker to perform privilege escalation via a crafted XML file. (Chromium security severity: Medium) | ||||
| CVE-2026-11041 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-06-08 | 8.8 High |
| Insufficient validation of untrusted input in Media in Google Chrome on Windows prior to 149.0.7827.53 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-43073 | 1 Linux | 1 Linux Kernel | 2026-06-07 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86-64: rename misleadingly named '__copy_user_nocache()' function This function was a masterclass in bad naming, for various historical reasons. It claimed to be a non-cached user copy. It is literally _neither_ of those things. It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses. Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86. The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal "start user space access" logic around it. But typically the user space access would be the source, not the non-temporal destination. That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully. Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer. However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak. Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination. Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller). Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all. | ||||