Export limit exceeded: 29163 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (29163 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-43011 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain: x25_queue_rx_frame returns 1 | v x25_state3_machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25_process_rx_frame returns queued=0 | v x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb) again This would free the same skb twice. Looking at x25_backlog_rcv: net/x25/x25_in.c:x25_backlog_rcv() { ... queued = x25_process_rx_frame(sk, skb); ... if (!queued) kfree_skb(skb); } | ||||
| CVE-2026-43009 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix incorrect pruning due to atomic fetch precision tracking When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a destination, thus receiving the old value from the memory location. The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads the backtrack_insn to fail to propagate precision to the stack location, which is then not marked as precise! Later, the verifier's path pruning can incorrectly consider two states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as equivalent and thus get pruned when they should not be seen as such. Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to also cover atomic fetch operations via is_atomic_fetch_insn() helper. When the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPF_LDX. This covers all fetch variants. Before: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit After: 0: (b7) r1 = 8 ; R1=8 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1 mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit | ||||
| CVE-2026-31468 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Fix double free in dma-buf feature The error path through vfio_pci_core_feature_dma_buf() ignores its own advice to only use dma_buf_put() after dma_buf_export(), instead falling through the entire unwind chain. In the unlikely event that we encounter file descriptor exhaustion, this can result in an unbalanced refcount on the vfio device and double free of allocated objects. Avoid this by moving the "put" directly into the error path and return the errno rather than entering the unwind chain. | ||||
| CVE-2026-26171 | 3 Apple, Linux, Microsoft | 5 Macos, Linux Kernel, .net and 2 more | 2026-05-07 | 7.5 High |
| Uncontrolled resource consumption in .NET allows an unauthorized attacker to deny service over a network. | ||||
| CVE-2025-14593 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted CATPART file, when parsed through certain Autodesk products, can force an Out-of-Bounds Read vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. | ||||
| CVE-2026-32178 | 3 Apple, Linux, Microsoft | 5 Macos, Linux Kernel, .net and 2 more | 2026-05-07 | 7.5 High |
| Improper neutralization of special elements in .NET allows an unauthorized attacker to perform spoofing over a network. | ||||
| CVE-2025-10900 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted MODEL file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10899 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted MODEL file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10898 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted MODEL file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10889 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted CATPART file, when parsed through certain Autodesk products, can force a Memory corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10888 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted MODEL file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10887 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted MODEL file, when parsed through certain Autodesk products, can force a Memory corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10886 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted MODEL file, when parsed through certain Autodesk products, can force a Memory corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10884 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted CATPART file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10883 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted CATPRODUCT file, when parsed through certain Autodesk products, can force an Out-of-Bounds Read vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. | ||||
| CVE-2026-31743 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: nvmem: zynqmp_nvmem: Fix buffer size in DMA and memcpy Buffer size used in dma allocation and memcpy is wrong. It can lead to undersized DMA buffer access and possible memory corruption. use correct buffer size in dma_alloc_coherent and memcpy. | ||||
| CVE-2025-10882 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| AA maliciously crafted X_T file, when parsed through certain Autodesk products, can force an Out-of-Bounds Write vulnerability. A malicious actor may leverage this vulnerability to cause a crash, cause data corruption, or execute arbitrary code in the context of the current process. | ||||
| CVE-2025-10881 | 1 Autodesk | 16 3ds Max, Advance Steel, Autocad and 13 more | 2026-05-07 | 7.8 High |
| A maliciously crafted CATPRODUCT file, when parsed through certain Autodesk products, can force a Heap-Based Overflow vulnerability. A malicious actor can leverage this vulnerability to cause a crash, read sensitive data, or execute arbitrary code in the context of the current process. | ||||
| CVE-2026-31442 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible invalid memory access after FLR In the case that the first Function Level Reset (FLR) concludes correctly, but in the second FLR the scratch area for the saved configuration cannot be allocated, it's possible for a invalid memory access to happen. Always set the deallocated scratch area to NULL after FLR completes. | ||||
| CVE-2026-31444 | 1 Linux | 1 Linux Kernel | 2026-05-07 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free and NULL deref in smb_grant_oplock() smb_grant_oplock() has two issues in the oplock publication sequence: 1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node. 2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL. Fix by restructuring the publication sequence to eliminate post-publish failure: - Set opinfo->o_fp before any list publication (fixes NULL deref). - Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication. - Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant. - Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used. This also requires splitting add_lease_global_list() to take a preallocated lease_table and changing its return type from int to void, since it can no longer fail. | ||||