Export limit exceeded: 74978 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (74978 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-20631 | 1 Apple | 1 Macos | 2026-04-02 | 8.4 High |
| A logic issue was addressed with improved checks. This issue is fixed in macOS Tahoe 26.4. A user may be able to elevate privileges. | ||||
| CVE-2024-27869 | 1 Apple | 4 Ios And Ipados, Ipados, Iphone Os and 1 more | 2026-04-02 | 7.5 High |
| The issue was addressed with improved checks. This issue is fixed in iOS 18 and iPadOS 18, macOS Sequoia 15. An app may be able to record the screen without an indicator. | ||||
| CVE-2025-43239 | 1 Apple | 4 Macos, Macos Sequoia, Macos Sonoma and 1 more | 2026-04-02 | 7.1 High |
| An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. Processing a maliciously crafted file may lead to unexpected app termination. | ||||
| CVE-2025-43281 | 1 Apple | 2 Macos, Macos Sequoia | 2026-04-02 | 7.8 High |
| The issue was addressed with improved authentication. This issue is fixed in macOS Sequoia 15.6. A local attacker may be able to elevate their privileges. | ||||
| CVE-2024-44306 | 1 Apple | 1 Macos | 2026-04-02 | 7.8 High |
| A buffer overflow issue was addressed with improved memory handling. This issue is fixed in macOS Sonoma 14.6. An app may be able to execute arbitrary code with kernel privileges. | ||||
| CVE-2024-44189 | 1 Apple | 1 Macos | 2026-04-02 | 7.5 High |
| The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15. A logic issue existed where a process may be able to capture screen contents without user consent. | ||||
| CVE-2026-20610 | 1 Apple | 1 Macos | 2026-04-02 | 7.8 High |
| This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Tahoe 26.3. An app may be able to gain root privileges. | ||||
| CVE-2024-40867 | 1 Apple | 3 Ios, Ipados, Iphone Os | 2026-04-02 | 8.8 High |
| A custom URL scheme handling issue was addressed with improved input validation. This issue is fixed in iOS 18.1 and iPadOS 18.1. A remote attacker may be able to break out of Web Content sandbox. | ||||
| CVE-2025-43188 | 1 Apple | 2 Macos, Macos Sequoia | 2026-04-02 | 7.8 High |
| A permissions issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.6. A malicious app may be able to gain root privileges. | ||||
| CVE-2025-69051 | 1 Wordpress | 1 Wordpress | 2026-04-02 | 7.1 High |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in CridioStudio ListingPro Reviews listingpro-reviews allows Reflected XSS.This issue affects ListingPro Reviews: from n/a through < 2.9.11. | ||||
| CVE-2025-68864 | 2 Infility, Wordpress | 2 Infility Global, Wordpress | 2026-04-02 | 7.1 High |
| Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Infility Infility Global infility-global allows Stored XSS.This issue affects Infility Global: from n/a through <= 2.15.06. | ||||
| CVE-2026-23239 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: espintcp: Fix race condition in espintcp_close() This issue was discovered during a code audit. After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk. The following is a simple race scenario: cpu0 cpu1 espintcp_close() cancel_work_sync(&ctx->work); espintcp_write_space() schedule_work(&ctx->work); To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync(). | ||||
| CVE-2026-23236 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.3 High |
| In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: properly copy ioctl memory to kernelspace The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from userspace to kernelspace, and instead directly references the memory, which can cause problems if invalid data is passed from userspace. Fix this all up by correctly copying the memory before accessing it within the kernel. | ||||
| CVE-2026-23231 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix use-after-free in nf_tables_addchain() nf_tables_addchain() publishes the chain to table->chains via list_add_tail_rcu() (in nft_chain_add()) before registering hooks. If nf_tables_register_hook() then fails, the error path calls nft_chain_del() (list_del_rcu()) followed by nf_tables_chain_destroy() with no RCU grace period in between. This creates two use-after-free conditions: 1) Control-plane: nf_tables_dump_chains() traverses table->chains under rcu_read_lock(). A concurrent dump can still be walking the chain when the error path frees it. 2) Packet path: for NFPROTO_INET, nf_register_net_hook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nft_do_chain() via the transient IPv4 hook can still be dereferencing chain->blob_gen_X when the error path frees the chain. Add synchronize_rcu() between nft_chain_del() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed. | ||||
| CVE-2026-23230 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: split cached_fid bitfields to avoid shared-byte RMW races is_open, has_lease and on_list are stored in the same bitfield byte in struct cached_fid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can restore stale values of the others. A possible interleaving is: CPU1: load old byte (has_lease=1, on_list=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits To avoid this class of races, convert these flags to separate bool fields. | ||||
| CVE-2026-23227 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock. | ||||
| CVE-2026-23226 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock to protect ksmbd_chann_list xarray ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del). Adds rw_semaphore chann_lock to struct ksmbd_session and protects all xa_load/xa_store/xa_erase accesses. | ||||
| CVE-2026-23225 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't assume CID is CPU owned on mode switch Shinichiro reported a KASAN UAF, which is actually an out of bounds access in the MMCID management code. CPU0 CPU1 T1 runs in userspace T0: fork(T4) -> Switch to per CPU CID mode fixup() set MM_CID_TRANSIT on T1/CPU1 T4 exit() T3 exit() T2 exit() T1 exit() switch to per task mode ---> Out of bounds access. As T1 has not scheduled after T0 set the TRANSIT bit, it exits with the TRANSIT bit set. sched_mm_cid_remove_user() clears the TRANSIT bit in the task and drops the CID, but it does not touch the per CPU storage. That's functionally correct because a CID is only owned by the CPU when the ONCPU bit is set, which is mutually exclusive with the TRANSIT flag. Now sched_mm_cid_exit() assumes that the CID is CPU owned because the prior mode was per CPU. It invokes mm_drop_cid_on_cpu() which clears the not set ONCPU bit and then invokes clear_bit() with an insanely large bit number because TRANSIT is set (bit 29). Prevent that by actually validating that the CID is CPU owned in mm_drop_cid_on_cpu(). | ||||
| CVE-2026-23224 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue for file-backed mounts w/ directio option [ 9.269940][ T3222] Call trace: [ 9.269948][ T3222] ext4_file_read_iter+0xac/0x108 [ 9.269979][ T3222] vfs_iocb_iter_read+0xac/0x198 [ 9.269993][ T3222] erofs_fileio_rq_submit+0x12c/0x180 [ 9.270008][ T3222] erofs_fileio_submit_bio+0x14/0x24 [ 9.270030][ T3222] z_erofs_runqueue+0x834/0x8ac [ 9.270054][ T3222] z_erofs_read_folio+0x120/0x220 [ 9.270083][ T3222] filemap_read_folio+0x60/0x120 [ 9.270102][ T3222] filemap_fault+0xcac/0x1060 [ 9.270119][ T3222] do_pte_missing+0x2d8/0x1554 [ 9.270131][ T3222] handle_mm_fault+0x5ec/0x70c [ 9.270142][ T3222] do_page_fault+0x178/0x88c [ 9.270167][ T3222] do_translation_fault+0x38/0x54 [ 9.270183][ T3222] do_mem_abort+0x54/0xac [ 9.270208][ T3222] el0_da+0x44/0x7c [ 9.270227][ T3222] el0t_64_sync_handler+0x5c/0xf4 [ 9.270253][ T3222] el0t_64_sync+0x1bc/0x1c0 EROFS may encounter above panic when enabling file-backed mount w/ directio mount option, the root cause is it may suffer UAF in below race condition: - z_erofs_read_folio wq s_dio_done_wq - z_erofs_runqueue - erofs_fileio_submit_bio - erofs_fileio_rq_submit - vfs_iocb_iter_read - ext4_file_read_iter - ext4_dio_read_iter - iomap_dio_rw : bio was submitted and return -EIOCBQUEUED - dio_aio_complete_work - dio_complete - dio->iocb->ki_complete (erofs_fileio_ki_complete()) - kfree(rq) : it frees iocb, iocb.ki_filp can be UAF in file_accessed(). - file_accessed : access NULL file point Introduce a reference count in struct erofs_fileio_rq, and initialize it as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will decrease reference count, the last one decreasing the reference count to zero will free rq. | ||||
| CVE-2026-23222 | 1 Linux | 1 Linux Kernel | 2026-04-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size. | ||||