Export limit exceeded: 386349 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 386349 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (36297 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53027 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked() When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments. The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1). Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup. The following scenario triggers the bug: attr_data_get_block_locked() vcn = vcn0 & cmask <- vcn != vcn0 after frame alignment load runs for vcn segment <- vcn0 segment not loaded! attr_allocate_clusters() <- allocation succeeds run_lookup_entry(vcn0) <- vcn0 not in run -> SPARSE_LCN WARN_ON(1) <- bug fires here! | ||||
| CVE-2026-52972 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Cap AEAD AD length to 0x80000000 In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. | ||||
| CVE-2026-45944 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Clear Present bit before tearing down context entry When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults. While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake: 1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software. 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU. 3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry. 4. Fully zero out the entry only after the invalidation is complete. Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible. | ||||
| CVE-2026-43119 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: annotate data-races around hdev->req_status __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock: hdev->req_status = HCI_REQ_PEND; However, several other functions read or write hdev->req_status without holding any lock: - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue) - hci_cmd_sync_complete() reads/writes from HCI event completion - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write - hci_abort_conn() reads in connection abort path Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race. Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering). | ||||
| CVE-2025-38550 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2026-07-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return. | ||||
| CVE-2024-27390 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well. | ||||
| CVE-2022-49662 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: fix lockdep splat in in6_dump_addrs() As reported by syzbot, we should not use rcu_dereference() when rcu_read_lock() is not held. WARNING: suspicious RCU usage 5.19.0-rc2-syzkaller #0 Not tainted net/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223 stack backtrace: CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ||||
| CVE-2026-15719 | 1 Mozilla | 1 Firefox | 2026-07-23 | 5.4 Medium |
| We are aware that exploit code for this is public however we are not aware of any attacks in the wild abusing this flaw. This vulnerability was fixed in Firefox 152.0.6, Firefox ESR 115.38, Firefox ESR 140.13, and Thunderbird 140.13. | ||||
| CVE-2024-30094 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 7.8 High |
| Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability | ||||
| CVE-2024-30091 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 7.8 High |
| Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2024-30087 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 7.8 High |
| Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2024-30063 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 6.7 Medium |
| Windows Distributed File System (DFS) Remote Code Execution Vulnerability | ||||
| CVE-2024-30082 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 7.8 High |
| Win32k Elevation of Privilege Vulnerability | ||||
| CVE-2024-30078 | 1 Microsoft | 23 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 20 more | 2026-07-20 | 8.8 High |
| Windows Wi-Fi Driver Remote Code Execution Vulnerability | ||||
| CVE-2024-30077 | 1 Microsoft | 24 Windows 10 1507, Windows 10 1607, Windows 10 1809 and 21 more | 2026-07-20 | 8 High |
| Windows OLE Remote Code Execution Vulnerability | ||||
| CVE-2024-30075 | 1 Microsoft | 3 Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 Sp2 | 2026-07-20 | 8 High |
| Windows Link Layer Topology Discovery Protocol Remote Code Execution Vulnerability | ||||
| CVE-2024-30074 | 1 Microsoft | 3 Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 Sp2 | 2026-07-20 | 8 High |
| Windows Link Layer Topology Discovery Protocol Remote Code Execution Vulnerability | ||||
| CVE-2026-63805 | 1 Linux | 1 Linux Kernel | 2026-07-20 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: nx - fix nx_crypto_ctx_exit argument nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *. Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call. This fixes the following oops: BUG: Unable to handle kernel data access at 0xc0403effffffffc8 Faulting instruction address: 0xc000000000396cb4 Oops: Kernel access of bad area, sig: 11 [#15] Call Trace: nx_crypto_ctx_shash_exit+0x24/0x60 crypto_shash_exit_tfm+0x28/0x40 crypto_destroy_tfm+0x98/0x140 crypto_exit_ahash_using_shash+0x20/0x40 crypto_destroy_tfm+0x98/0x140 hash_release+0x1c/0x30 alg_sock_destruct+0x38/0x60 __sk_destruct+0x48/0x2b0 af_alg_release+0x58/0xb0 __sock_release+0x68/0x150 sock_close+0x20/0x40 __fput+0x110/0x3a0 sys_close+0x48/0xa0 system_call_exception+0x140/0x2d0 system_call_common+0xf4/0x258 .. which came from hardlink(1) opportunistically using AF_ALG. The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years. | ||||
| CVE-2026-53398 | 1 Linux | 1 Linux Kernel | 2026-07-20 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo(). | ||||
| CVE-2026-53375 | 1 Linux | 1 Linux Kernel | 2026-07-20 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: Prevent partial address patches In the case that only one of lo/hi is valid, the patching could result in a bad address written to in FW. | ||||