Filtered by vendor
Subscriptions
Total
35086 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-43360 | 1 Apple | 4 Ios, Ipad Os, Ipados and 1 more | 2026-04-28 | 5.5 Medium |
| The issue was addressed with improved UI. This issue is fixed in iOS 26 and iPadOS 26. Password fields may be unintentionally revealed. | ||||
| CVE-2025-43376 | 1 Apple | 7 Ios, Ipados, Iphone Os and 4 more | 2026-04-28 | 7.5 High |
| A logic issue was addressed with improved state management. This issue is fixed in Safari 26, iOS 18.7.7 and iPadOS 18.7.7, iOS 26 and iPadOS 26, macOS Tahoe 26, tvOS 26, visionOS 26, watchOS 26. A remote attacker may be able to view leaked DNS queries with Private Relay turned on. | ||||
| CVE-2026-31478 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2_calc_max_out_buf_len() expects the second argument (hdr2_len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value. | ||||
| CVE-2025-43393 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.2 Medium |
| A permissions issue was addressed with additional sandbox restrictions. This issue is fixed in macOS Tahoe 26.1. An app may be able to break out of its sandbox. | ||||
| CVE-2025-43351 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.5 Medium |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Tahoe 26.1. An app may be able to access protected user data. | ||||
| CVE-2025-43473 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.5 Medium |
| This issue was addressed with improved state management. This issue is fixed in macOS Tahoe 26.1. An app may be able to access sensitive user data. | ||||
| CVE-2025-43320 | 1 Apple | 2 Macos, Macos Sequoia | 2026-04-28 | 7.8 High |
| The issue was addressed by adding additional logic. This issue is fixed in macOS Sequoia 15.7.3, macOS Tahoe 26. An app may be able to bypass launch constraint protections and execute malicious code with elevated privileges. | ||||
| CVE-2025-43402 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 7.8 High |
| The issue was addressed with improved memory handling. This issue is fixed in macOS Sequoia 15.7.4, macOS Sonoma 14.8.4, macOS Tahoe 26.1. An app may be able to cause unexpected system termination or corrupt process memory. | ||||
| CVE-2025-43509 | 1 Apple | 3 Macos, Macos Sequoia, Macos Sonoma | 2026-04-28 | 5.5 Medium |
| This issue was addressed with improved data protection. This issue is fixed in macOS Sequoia 15.7.3, macOS Sonoma 14.8.3, macOS Tahoe 26.2. An app may be able to access sensitive user data. | ||||
| CVE-2025-43471 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.5 Medium |
| The issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.1. An app may be able to access sensitive user data. | ||||
| CVE-2025-43467 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 7.8 High |
| This issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.1. An app may be able to gain root privileges. | ||||
| CVE-2025-46277 | 1 Apple | 6 Ios, Ipad Os, Ipados and 3 more | 2026-04-28 | 5.5 Medium |
| A logging issue was addressed with improved data redaction. This issue is fixed in iOS 26.2 and iPadOS 26.2, macOS Tahoe 26.2, watchOS 26.2. An app may be able to access a user’s Safari history. | ||||
| CVE-2025-46283 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5.5 Medium |
| A logic issue was addressed with improved validation. This issue is fixed in macOS Sonoma 14.8.4, macOS Tahoe 26.2. An app may be able to access sensitive user data. | ||||
| CVE-2025-46278 | 1 Apple | 2 Macos, Macos Tahoe | 2026-04-28 | 5 Medium |
| The issue was addressed with improved handling of caches. This issue is fixed in macOS Tahoe 26.2. An app may be able to access protected user data. | ||||
| CVE-2025-71089 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommu: disable SVA when CONFIG_X86 is set Patch series "Fix stale IOTLB entries for kernel address space", v7. This proposes a fix for a security vulnerability related to IOMMU Shared Virtual Addressing (SVA). In an SVA context, an IOMMU can cache kernel page table entries. When a kernel page table page is freed and reallocated for another purpose, the IOMMU might still hold stale, incorrect entries. This can be exploited to cause a use-after-free or write-after-free condition, potentially leading to privilege escalation or data corruption. This solution introduces a deferred freeing mechanism for kernel page table pages, which provides a safe window to notify the IOMMU to invalidate its caches before the page is reused. This patch (of 8): In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardware shares and walks the CPU's page tables. The x86 architecture maps the kernel's virtual address space into the upper portion of every process's page table. Consequently, in an SVA context, the IOMMU hardware can walk and cache kernel page table entries. The Linux kernel currently lacks a notification mechanism for kernel page table changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual address mappings. This can cause the IOMMU's internal caches to retain stale entries for kernel VA. Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise when kernel page table pages are freed and later reallocated. The IOMMU could misinterpret the new data as valid page table entries. The IOMMU might then walk into attacker-controlled memory, leading to arbitrary physical memory DMA access or privilege escalation. This is also a Write-After-Free issue, as the IOMMU will potentially continue to write Accessed and Dirty bits to the freed memory while attempting to walk the stale page tables. Currently, SVA contexts are unprivileged and cannot access kernel mappings. However, the IOMMU will still walk kernel-only page tables all the way down to the leaf entries, where it realizes the mapping is for the kernel and errors out. This means the IOMMU still caches these intermediate page table entries, making the described vulnerability a real concern. Disable SVA on x86 architecture until the IOMMU can receive notification to flush the paging cache before freeing the CPU kernel page table pages. | ||||
| CVE-2026-31628 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. | ||||
| CVE-2026-31575 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: fix hugetlb fault mutex hash calculation In mfill_atomic_hugetlb(), linear_page_index() is used to calculate the page index for hugetlb_fault_mutex_hash(). However, linear_page_index() returns the index in PAGE_SIZE units, while hugetlb_fault_mutex_hash() expects the index in huge page units. This mismatch means that different addresses within the same huge page can produce different hash values, leading to the use of different mutexes for the same huge page. This can cause races between faulting threads, which can corrupt the reservation map and trigger the BUG_ON in resv_map_release(). Fix this by introducing hugetlb_linear_page_index(), which returns the page index in huge page granularity, and using it in place of linear_page_index(). | ||||
| CVE-2026-31574 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: clockevents: Add missing resets of the next_event_forced flag The prevention mechanism against timer interrupt starvation missed to reset the next_event_forced flag in a couple of places: - When the clock event state changes. That can cause the flag to be stale over a shutdown/startup sequence - When a non-forced event is armed, which then prevents rearming before that event. If that event is far out in the future this will cause missed timer interrupts. - In the suspend wakeup handler. That led to stalls which have been reported by several people. Add the missing resets, which fixes the problems for the reporters. | ||||
| CVE-2026-31571 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915: Unlink NV12 planes earlier unlink_nv12_plane() will clobber parts of the plane state potentially already set up by plane_atomic_check(), so we must make sure not to call the two in the wrong order. The problem happens when a plane previously selected as a Y plane is now configured as a normal plane by user space. plane_atomic_check() will first compute the proper plane state based on the userspace request, and unlink_nv12_plane() later clears some of the state. This used to work on account of unlink_nv12_plane() skipping the state clearing based on the plane visibility. But I removed that check, thinking it was an impossible situation. Now when that situation happens unlink_nv12_plane() will just WARN and proceed to clobber the state. Rather than reverting to the old way of doing things, I think it's more clear if we unlink the NV12 planes before we even compute the new plane state. (cherry picked from commit 017ecd04985573eeeb0745fa2c23896fb22ee0cc) | ||||
| CVE-2026-31564 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Fix base address calculation in kvm_eiointc_regs_access() In function kvm_eiointc_regs_access(), the register base address is caculated from array base address plus offset, the offset is absolute value from the base address. The data type of array base address is u64, it should be converted into the "void *" type and then plus the offset. | ||||
ReportizFlow