Export limit exceeded: 395619 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (395619 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-76755 | 1 Drupal | 1 Gammu Sms Daemon | 2026-09-19 | 5.9 Medium |
| Vulnerability in Drupal Gammu SMS Daemon. This issue affects Gammu SMS Daemon versions: *.*. | ||||
| CVE-2026-90281 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: phy: qcom: snps-femto-v2: Fix possible NULL-deref on early runtime suspend Runtime PM must be enabled before creating the PHY, since phy_create() only enables runtime PM on the PHY device if it is already enabled on this parent device. However, the runtime PM callbacks dereference the hsphy instance, which is not yet ready, leaving a window where a suspend callback may trigger a NULL pointer dereference. Take a runtime PM usage reference with pm_runtime_get_noresume() before enabling runtime PM and release it once the PHY has been created, so that no runtime suspend can run before the PHY is ready. This also prevents a short window where an unnecessary runtime suspend can occur. Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup. | ||||
| CVE-2026-90283 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: hugetlbfs: release subpool on fill_super failure hugetlbfs_fill_super() allocates a hugepage subpool when size or min_size mount options are specified. hugepage_new_subpool() may also reserve huge pages for min_size. If root dentry creation fails after the subpool is created, the failure path frees the subpool with kfree(). This bypasses hugepage_put_subpool() and can leave min_size reservations charged. Use hugepage_put_subpool() on the failure path, matching the normal put_super path. | ||||
| CVE-2026-90284 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: firmware_loader: do not queue completed sysfs fallback requests fw_load_sysfs_fallback() calls device_add() before adding the fw_priv to pending_fw_head. device_add() publishes the fallback loading interface, so a userspace helper which discovers the device by scanning sysfs can write 0 to the loading attribute and complete the request before it is queued as pending. In that interleaving firmware_loading_store() calls fw_state_done() while pending_list still points to itself, so it cannot remove an entry from pending_fw_head. The subsequent unconditional list_add() then queues an already-completed fw_priv. Once the request is released, pending_fw_head can retain a pointer to freed memory and the next fallback request can fault while validating the list. Only in-flight fallback requests need suspend or reboot abort handling. If the request is already DONE after device_add(), return success from the fallback path without sending another uevent, waiting again, or queueing it as pending. This preserves the invariant that pending_fw_head contains only active fallback requests. | ||||
| CVE-2026-90299 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix sleepable check for tracing/lsm prog When CONFIG_FUNCTION_ERROR_INJECTION is disabled, a sleepable tracing prog is allowed to attach to '__x64_'-alike prefix symbols. It is because the verifier does not verify whether the symbol is a kernel function or a bpf prog. That said, a sleepable tracing prog is allowed to attach to a bpf prog target whose name has '__x64_'-alike prefix. For example, a sleepable fentry prog attaches to a '__x64_sys_nop' XDP prog, and copies buffer from a user pointer with bpf_copy_from_user() helper. After attaching the XDP prog to lo interface, the kernel BUG could be triggered by 'ping -c 1 -W 1 127.0.0.1': [ 3.460756] BUG: sleeping function called from invalid context at kernel/bpf/trampoline.c:1324 Fix it by disallowing sleepable prog always when its target btf is not a kernel's btf. | ||||
| CVE-2026-90301 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that path: region lifecycle: late negotiate callback: 1. make_item() registers the 1. o2net_process_message() gets a region handlers before heartbeat handler for reg. dev_store() has built a 2. The callback runs after the lookup runnable heartbeat context. lock is dropped and dereferences reg. 2. A failed start or rmdir 3. An approve or timeout path tries to stops the heartbeat thread, queue reg's delayed work, or release quiesces existing work, and races the callback body after handler drops the final configfs ref. unregister. 3. region_release() must drain 4. The callback or delayed work can handler-visible o2net rx work outlive reg unless lifecycle code before freeing reg. keeps the region non-armable and drains the active-or-destroying o2net workqueue. Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 __run_timers+0x22c/0x5b0 kasan_report+0xe0/0x110 _raw_spin_unlock_irqrestore+0x27/0x60 try_to_wake_up+0x191/0xf70 timer_expire_remote+0xae/0xf0 run_timer_softirq+0x19b/0x1a0 handle_softirqs+0x156/0x660 __irq_exit_rcu+0xc4/0x160 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x6c/0x80 asm_sysvec_apic_timer_interrupt+0x1a/0x20 Allocated by task stack: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 o2hb_heartbeat_group_make_item+0x3c/0x600 | ||||
| CVE-2026-90316 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/omap: dsi: Do not copy isr table To be able to unregister stuff from isrs, the corresponding table was copied. Nobody seems to unregister stuff that way, so it does not help. But there are stack-allocated objects passed to these isrs giving chances of UAF of these objects if irqs are unregistered while they are handled, so better do not copy that table. | ||||
| CVE-2026-90319 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: rapidio: clear mport->net when rio_add_net() fails rio_alloc_net() stores the newly allocated rio_net in mport->net before rio_scan_alloc_net() registers the device. If rio_add_net() fails, rio_scan_alloc_net() drops the device reference with put_device(), which releases the rio_net through the device release callback. However, mport->net is left pointing at the freed object. A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rio_net again. Clear mport->net in the rio_add_net() failure path, matching the cleanup done for the destID table allocation failure path. | ||||
| CVE-2026-90321 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate inline xattrs during inode block validation Patch series "ocfs2: validate xattr entry bounds", v7. This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata. This patch (of 2): ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers. The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds. Add a flat xattr entry validator and call it from inode block validation for inline xattrs. Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time. Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage. Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 kasan_report+0xe0/0x110 ocfs2_xattr_find_entry+0x5a/0x170 ocfs2_xattr_get_nolock+0x20a/0x820 ocfs2_xattr_get+0x10c/0x1e0 __vfs_getxattr+0xe2/0x130 vfs_getxattr+0x185/0x1b0 | ||||
| CVE-2026-90324 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ublk: check import_ubuf() return value import_ubuf() can fail if the address range (provided by the userspace ublk server) is outside the allowed user address space. Return that 0 bytes were copied if import_ubuf() fails rather than passing an uninitialized struct iov_iter to ublk_copy_user_pages(). | ||||
| CVE-2026-90325 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: skip dying blkg in blkcg_activate_policy() When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs. T1: T2: blkg_destroy kill(&blkg->refcnt) // blkg->refcnt=1->0 blkg_release // call_rcu(__blkg_release) ... blkg_free_workfn ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1 list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed. | ||||
| CVE-2026-90330 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix FF device cleanup on init failure hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue. If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds. | ||||
| CVE-2026-90332 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush cached MSI write before unmapping the iATU The MSI-X path already flushes any posted MSI-X write before tearing down its iATU mapping. That was added by commit c22533c66cca ("PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry") to make sure the write reaches the Root Complex before the outbound window that translates it disappears. The MSI path has the same problem but no equivalent flush. When the Endpoint driver caches an MSI target address and later observes that the Root Complex has changed it, dw_pcie_ep_raise_msi_irq() unmaps the existing iATU entry and reprograms it for the new address. Between the last MSI writel() and the unmap there may still be a posted write sitting in the fabric, and unmapping the iATU entry can drop or misroute that write. Fix this by reading back from the mapped MSI window before the unmap. The readback drains any posted MSI writes through the same iATU entry that mapped them, which is the same logic the MSI-X path uses. [mani: commit log] | ||||
| CVE-2026-90339 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/syscall: Fix syscall skip handling for seccomp and ptrace After enabling GENERIC_ENTRY on PowerPC, syscall_enter_from_user_mode() returns -1 as a sentinel to signal that seccomp or ptrace has intercepted the syscall and already set a return value via syscall_set_return_value(). system_call_exception() was not handling this sentinel, and since -1UL is >= NR_syscalls, the code fell into the out-of-range path and returned -ENOSYS, overwriting the errno already placed in regs->gpr[3]. The naive fix of checking r0 == -1L before the NR_syscalls bounds check is ambiguous: a user legitimately calling syscall(-1) also produces r0 == -1L, and a tracer intercepting such a call would have its injected return value silently discarded. Fix this by introducing a thread flag that is set whenever syscall_set_return_value() explicitly updates the return value. In system_call_exception(), check and clear this flag before dispatching the syscall, and return the preset value directly when it is present. This ensures that an explicitly supplied return value always suppresses syscall execution, regardless of the syscall number. This handles all seccomp actions correctly: - SECCOMP_RET_ERRNO, SECCOMP_RET_TRACE (no tracer), SECCOMP_RET_USER_NOTIF: all call syscall_set_return_value(), flag is set, injected value returned. - SECCOMP_RET_TRAP, SECCOMP_RET_KILL: call syscall_rollback() and deliver a signal; flag is not set, but the process is dying so the return value is irrelevant. The fix covers both ppc32 and ppc64 with no #ifdefs. | ||||
| CVE-2026-90343 | 1 Linux | 1 Linux Kernel | 2026-09-19 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: stop PMSR before P2P and NAN teardown PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not. Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result. Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers. | ||||
| CVE-2026-90400 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: md: recheck spare changes before starting sync remove_spares() and remove_and_add_spares() modify the array's rdev configuration. These operations are only safe after the array has been suspended. md_start_sync() checks whether spare configuration changes are needed before taking reconfig_mutex. However, the rdev state can change before the mutex is acquired, so the initial check can become stale. In that case, md_choose_sync_action() may remove or replace rdevs while normal I/O is still accessing them. The race can occur as follows: raid10d Worker Normal IO ____________ _______________________ ______________________ raid10_write_request() wait_blocked_dev() set Blocked set Faulty Skip Faulty rdev rrdev->nr_pending++ .repl_bio = bio removeable_rdev = false . array not suspended . lock mddev goto err_handle lock mddev (wait) . update sb . clear Blocked . . unlock mddev . lock mddev (acquires) remove_spares() removeable_rdev = true raid10_remove_disk() rdev = replacement replacement = NULL rdev_dec_pending(NULL) unlock mddev (NULL)->nr_pending-- In this case, rdev_dec_pending() is called with a NULL pointer, resulting in a NULL pointer dereference when attempting to decrement nr_pending. Fix this by suspending the array when spare configuration changes are needed, including for non-read-write arrays, and checking again after taking reconfig_mutex. If the array was not already suspended and a change is now needed, release the mutex, suspend the array, and reacquire the mutex before continuing. | ||||
| CVE-2026-90417 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry() When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free. Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem(). | ||||
| CVE-2026-93071 | 1 Linux | 1 Linux Kernel | 2026-09-19 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: bcm2835-unicam: Fix asc leaked in error/remove path v4l2_async_nf_add_fwnode_remote() allocates the asc, which is freed when v4l2_async_nf_cleanup() is called. Call v4l2_async_nf_cleanup() properly in the driver paths. Discovered with kmemleak after rmmod: unreferenced object 0xffff000084526b80 (size 64): comm "modprobe", pid 185, jiffies 4295013512 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 e8 0d ff bf 00 00 ff ff ................ 40 83 bc 84 00 00 ff ff 60 83 bc 84 00 00 ff ff @.......`....... backtrace (crc ac584083): [<00000000ffb081a7>] kmemleak_alloc+0x38/0x44 [<00000000d2fd9301>] __kmalloc+0x1b0/0x250 [<000000004dd5354d>] __v4l2_async_nf_add_fwnode+0x28/0x9c [<0000000067587657>] __v4l2_async_nf_add_fwnode_remote+0x3c/0x64 | ||||
| CVE-2026-9855 | 2026-09-19 | 6.5 Medium | ||
| The Custom Field Template plugin for WordPress is vulnerable to generic SQL Injection via the 'post_ID' parameter in all versions up to, and including, 2.7.8 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with contributor-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. The capability check via current_user_can('edit_post', $id) is bypassable because WordPress internally casts $id to an integer for the permission evaluation while the full unsanitized string is preserved and passed to the SQL sink, and a valid nonce — which is also required — can be legitimately obtained by any Contributor-level user from the post edit screen. | ||||
| CVE-2026-9832 | 2026-09-19 | 5.3 Medium | ||
| The Payment Gateway of Stripe for WooCommerce plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in all versions up to, and including, 5.0.8. This is due to the publicly accessible `woocommerce_api_wt_stripe` webhook endpoint (`EH_Stripe_Webhook_Handler::handle()`) wrapping the only call to `\Stripe\Webhook::constructEvent()` inside an `if (!empty($endpoint_secret))` guard that is never entered on default installations — because the `eh_stripe_webhook_secret` option is empty after a fresh plugin install — causing the raw, attacker-controlled POST body to be decoded and processed as a fully trusted Stripe event without any signature verification, authentication, or authorization. This makes it possible for unauthenticated attackers to send forged Stripe webhook events to manipulate WooCommerce order statuses, including marking unpaid orders as paid or completed via `payment_complete()`, forcing legitimate orders into a failed state, fabricating dispute notifications, and injecting forged refund events. This vulnerability is only exploitable when the Stripe webhook signing secret has not been configured by an administrator; once a valid signing secret is saved, `\Stripe\Webhook::constructEvent()` is enforced and forged requests are rejected. | ||||