Export limit exceeded: 35533 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (35533 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-43515 | 1 Microsoft | 25 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 22 more | 2026-06-09 | 7.5 High |
| Internet Small Computer Systems Interface (iSCSI) Denial of Service Vulnerability | ||||
| CVE-2024-43513 | 1 Microsoft | 22 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 19 more | 2026-06-09 | 6.4 Medium |
| BitLocker Security Feature Bypass Vulnerability | ||||
| CVE-2024-43508 | 1 Microsoft | 8 Windows 11 22h2, Windows 11 22h2, Windows 11 23h2 and 5 more | 2026-06-09 | 5.5 Medium |
| Windows Graphics Component Information Disclosure Vulnerability | ||||
| CVE-2024-43506 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-06-09 | 7.5 High |
| BranchCache Denial of Service Vulnerability | ||||
| CVE-2024-43505 | 1 Microsoft | 6 365 Apps, Office, Office 2019 and 3 more | 2026-06-09 | 7.8 High |
| Microsoft Office Visio Remote Code Execution Vulnerability | ||||
| CVE-2024-43504 | 1 Microsoft | 8 365 Apps, Excel, Excel 2016 and 5 more | 2026-06-09 | 7.8 High |
| Microsoft Excel Remote Code Execution Vulnerability | ||||
| CVE-2024-43503 | 1 Microsoft | 3 Sharepoint Server, Sharepoint Server 2016, Sharepoint Server 2019 | 2026-06-09 | 7.8 High |
| Microsoft SharePoint Elevation of Privilege Vulnerability | ||||
| 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) | ||||