Export limit exceeded: 399431 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (399431 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-93254 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit Currently, when exiting to kernel mode, we attempt involuntary preemption. The preemption logic expects IRQs to be disabled, which is why we call local_irq_disable() before attempting preemption. However, depending on the context, local_irq_disable() may be unnecessary: - __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so local_irq_disable() is redundant. - irqentry_exit_to_kernel_mode_preempt() immediately returns when exiting from an NMI-like context, so calling local_irq_disable() beforehand is unnecessary work. Furthermore, it confuses the pNMI state tracking when we are in a context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set in the PMR, leading to a warning when CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y: WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805 CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--) pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) lr : el1_abort (arch/arm64/kernel/entry-common.c:323) pmr: 000000f0 Call trace: arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P) el1_abort (arch/arm64/kernel/entry-common.c:323) el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449) el1h_64_sync (arch/arm64/kernel/entry.S:589) [...] Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and dispatch parts so that we can avoid this extra work where it is not needed and avoid breaking the pNMI tracking logic. | ||||
| CVE-2026-93262 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: md/raid5-ppl: fix use-after-free in ppl_do_flush() The loop in ppl_do_flush() continues iterating after calling ppl_io_unit_finished(), touching io->pending_flushes and leading to a use-after-free. Add a break statement to stop the loop once io is freed. | ||||
| CVE-2026-93266 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64: RSI: fix field-spanning write warning in attestation token init The challenge is passed in registers a1 through a8. However, copying to ®s.a1 makes FORTIFY treat the destination as the single a1 field, resulting in a field-spanning write warning. [1] Overlay the SMCCC register structure with an RSI-specific argument layout and copy the challenge into an explicit 64-byte array. This keeps the existing a1-a8 argument encoding while giving the copy a correctly sized destination object. [1] memcpy: detected field-spanning write (size 64) of single field "®s.a1" at ./arch/arm64/include/asm/rsi_cmds.h:119 (size 8) WARNING: ./arch/arm64/include/asm/rsi_cmds.h:119 at rsi_attestation_token_init+0xdc/0xf8 [arm_cca_guest], CPU#0: cat/3314 | ||||
| CVE-2026-97474 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 7.4 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mld: purge async notifications upon nic error This fixes a kernel panic in reconfig failure: 1. we have a BSS connection 2. we have a NAN connection 3. FW error occurs 4. reconfig restores the BSS connection 5. however, restoring the NAN connection fails due to a FW error. 6. erroneously, ieee80211_handle_reconfig_failure is called and marks all interfaces as not-in-driver (will be fixed in a different patch). 7. mac80211 frees the links of the BSS connection but doesn't tell the driver about that, as it thinks that this vif is not in the driver. 8. in ieee80211_stop_device, *ALL* wiphy works are getting flushed (erroneously?) 9. Therefore, async_handlers_wk is being executed, processing the statistics notification that was received after we restored the BSS connection. 10. the notification handler dereferences fw_id_to_bss_conf[id], which is now a dangling pointer, as mac80211 already freed this link in (7). 11. On the first access to one of the links fields, we panic. While this can and should be fixed by removing the call to ieee80211_handle_reconfig_failure in (6), it is also not a good idea to carry and maybe handle notifications from a dead FW. We do purge the notifications when we stop the FW, but in reconfig failure we stop the FW too late, after the notifications are processed. In addition, async_handlers_wk can always be scheduled before the reconfig work. Purge the notifications immediately when transport notifies about a nic error. | ||||
| CVE-2026-98101 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source() pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths. ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array. Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries. Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter(). Also remove the now unused IP6_SFBLOCK macro. | ||||
| CVE-2026-98109 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix race condition during device registration In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: <TASK> msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed. | ||||
| CVE-2026-97622 | 2026-09-25 | N/A | ||
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-62062. Reason: This candidate is a reservation duplicate of CVE-2026-62062. Notes: All CVE users should reference CVE-2026-62062 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage. | ||||
| CVE-2026-58004 | 1 Altera | 1 Trusted Firmware | 2026-09-25 | 8.1 High |
| Out-of-bounds read vulnerability in Altera Trusted Firmware on HPS allows Privilege Escalation and Overflow Buffers. This issue affects Trusted Firmware: through socfpga_v2.14.0. | ||||
| CVE-2026-58005 | 1 Altera | 1 Trusted Firmware | 2026-09-25 | 8.1 High |
| Out-of-bounds read vulnerability in Altera Trusted Firmware on HPS allows Privilege Escalation and Overflow Buffers. This issue affects Trusted Firmware: through socfpga_v2.14.0. | ||||
| CVE-2026-58006 | 1 Altera | 1 Trusted Firmware | 2026-09-25 | 8.1 High |
| Untrusted pointer dereference vulnerability in Altera Trusted Firmware on HPS allows Exploitation of Improperly Configured or Implemented Memory Protections. This issue affects Trusted Firmware: through socfpga_v2.14.0. | ||||
| CVE-2026-58008 | 1 Altera | 1 Trusted Firmware | 2026-09-25 | 8.1 High |
| Stack-based buffer overflow vulnerability in Altera Trusted Firmware on HPS allows Exploitation of Improperly Configured or Implemented Memory Protections. This issue affects Trusted Firmware: through socfpga_v2.14.0. | ||||
| CVE-2026-93205 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Manage teardown with devm arm_smmu_device_remove() manually frees the IOPF queue, destroys the vmid_map and disables the device, while the IRQs and queues are devm managed. devm unwinds only after remove() returns, so the cleanup runs in the wrong order. The IOPF queue is freed before the event-queue IRQ whose handler uses it. Manage all of it with devm so the unwind order is correct. Free the IOPF queue and vmid_map via devm actions, and disable the device from one registered after arm_smmu_device_reset(). This is also a prerequisite for fixing a Tegra241 CMDQV CMD_SYNC use-after-free in the subsequent patch. | ||||
| CVE-2026-93207 | 1 Linux | 1 Linux Kernel | 2026-09-25 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Zero rpc_gss_wire_cred at svcauth_gss_decode_credbody() entry svcauth_gss_decode_credbody() writes the caller's rpc_gss_wire_cred field by field and assigns gc_ctx.len only on the success tail. The caller storage is svcdata->clcred, which lives in the per-svc_rqst gss_svc_data and is reused across requests. Early decode failures leave partially decoded state mixed with residue from the prior request. The trailing body_len tightness check is the sharpest case: xdr_stream_decode_opaque_inline() has already written gc_ctx.data with a borrowed inline pointer into the current request's XDR pages, but gc_ctx.len retains its prior value. Once the request pages are released the pooled clcred carries a dangling pointer paired with a stale length. Zero the caller's rpc_gss_wire_cred at function entry so that every early-return path leaves a deterministic all-zero cred. On the trailing tightness-check path, gc_ctx.len is now zero instead of stale, which neuters length-driven consumers such as gss_svc_searchbyctx() that would otherwise walk the dangling data pointer. | ||||
| CVE-2026-93211 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: initialize DRC hash table before registering shrinker shrinker_register() precedes the INIT_LIST_HEAD loop and the drc_hashsize store. On weakly-ordered architectures (arm64, ppc), a shrinker scan can observe drc_hashsize before the bucket list heads are initialized, causing a NULL deref in the DRC shrinker callback. Move bucket initialization and the drc_hashsize store before shrinker_register() so the hash table is fully initialized before it becomes visible to the shrinker. | ||||
| CVE-2026-93212 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: guard nfsd_serv deref in nfsd_file_net_dispose nfsd_file_net_dispose() is the consumer side of l->freeme: the nfsd service thread loop calls it to drain entries that the filecache garbage collector and shrinker append via nfsd_file_dispose_list_delayed(). During per-net teardown, nn->nfsd_serv is cleared before the filecache laundrette is shut down, so the service thread can still run a dispose pass that finds more than eight entries on l->freeme and dereferences a NULL svc_serv: nfsd service thread loop nfsd_file_net_dispose(nn) if (!list_empty(&l->freeme)) { ... svc_wake_up(nn->nfsd_serv); /* nn->nfsd_serv == NULL */ } The sibling helper nfsd_file_dispose_list_delayed() already documents this ordering and caches nn->nfsd_serv into a local before testing it for NULL. nfsd_file_net_dispose() was introduced with the same raw svc_wake_up(nn->nfsd_serv) call and never picked up the guard. Fix by loading nn->nfsd_serv into a local svc_serv pointer and only calling svc_wake_up() when it is non-NULL, matching the pattern in nfsd_file_dispose_list_delayed(). | ||||
| CVE-2026-93214 | 1 Linux | 1 Linux Kernel | 2026-09-25 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: fix deadlock in usbg_make_tpg() usbg_make_tpg() held dep_lock while calling configfs_depend_item_unlocked(), which acquires the configfs root inode lock when operating across subsystems. This creates a circular lock dependency with configfs_rmdir(): dep_lock -> configfs root inode lock -> su_mutex -> dep_lock In usbg_make_tpg(), dep_lock only serialized the read of opts->ready, which is a monotonic flag that transitions from false to true exactly once (in tcm_set_name()) and never reverts. Remove dep_lock from usbg_make_tpg() entirely and use READ_ONCE/WRITE_ONCE to access opts->ready locklessly instead. | ||||
| CVE-2026-96766 | 2 Paoltaia, Wordpress | 2 Geodirectory – Wp Business Directory Plugin And Classified Listings Directory, Wordpress | 2026-09-25 | 6.4 Medium |
| The GeoDirectory – WP Business Directory Plugin and Classified Listings Directory plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'business_hours' parameter in all versions up to, and including, 2.8.183 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is possible because the AJAX save handler validates only post authorship and a nonce with no additional capability check, allowing any subscriber-level user who owns a listing to exploit this vulnerability. | ||||
| CVE-2026-96752 | 2026-09-25 | 7.2 High | ||
| The Zero Spam for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Nested POST Array Keys via Contact Form 7 Integration in all versions up to, and including, 5.7.10 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The payload is delivered by submitting a Contact Form 7 request with a nested POST array key containing arbitrary HTML or JavaScript — PHP parses the field name into a nested array key, which is stored verbatim in the zerospam_log.submission_data column when Zero Spam flags the submission as spam due to the absence of the zerospam_david_walsh_key field. | ||||
| CVE-2026-93654 | 2 Codename065, Wordpress | 2 Premium Packages – Sell Digital Products Securely, Wordpress | 2026-09-25 | 7.2 High |
| The Premium Packages – Sell Digital Products Securely plugin for WordPress is vulnerable to Stored Cross-Site Scripting via 'cart_items[][product_name]' Parameter in all versions up to, and including, 7.2.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The checkout REST route uses permission_callback set to __return_true and the invoice loader performs no order ownership check, meaning an unauthenticated attacker can both persist the payload and ensure it is renderable to any logged-in user who accesses the invoice. | ||||
| CVE-2026-92799 | 2 Ladela, Wordpress | 2 Online Scheduling And Appointment Booking System – Bookly, Wordpress | 2026-09-25 | 5.3 Medium |
| The Online Scheduling and Appointment Booking System – Bookly plugin for WordPress is vulnerable to Authorization Bypass via PHP Type Juggling in all versions up to, and including, 28.2. This is due to the `postValidateCustomer()` function using a loose PHP inequality operator (`!=`) to compare the session-stored one-time verification code against the attacker-supplied `verification_code` parameter — a flaw that is further exposed by the booking AJAX controller registering all its methods as `wp_ajax_nopriv_` handlers and unconditionally overriding `csrfTokenValid()` to return true, leaving the endpoint both unauthenticated and CSRF-unprotected. This makes it possible for unauthenticated attackers to bypass the phone/email ownership verification step and overwrite the name, email, phone, and address fields of any arbitrary existing Bookly customer record, redirecting that customer's booking notifications to attacker-controlled contact details. The bypass is achievable because the `json_data` input channel decodes input via `json_decode()`, which preserves real PHP types and causes the `wp_kses` filter to leave non-string values such as the JSON boolean `true` untouched; submitting `true` as the `verification_code` satisfies the loose comparison against the session's non-zero integer code (generated by `mt_rand(100000, 999999)`), causing `true != <non-zero int>` to evaluate as `false` and the guard to be bypassed. | ||||