Search Results (3686 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-31535 1 Linux 1 Linux Kernel 2026-04-28 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: smb: client: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer.
CVE-2026-41488 2 Langchain, Langchain-ai 2 Langchain-openai, Langchain 2026-04-28 3.1 Low
LangChain is a framework for building agents and LLM-powered applications. Prior to 1.1.14, langchain-openai's _url_to_size() helper (used by get_num_tokens_from_messages for image token counting) validated URLs for SSRF protection and then fetched them in a separate network operation with independent DNS resolution. This left a TOCTOU / DNS rebinding window: an attacker-controlled hostname could resolve to a public IP during validation and then to a private/localhost IP during the actual fetch.
CVE-2026-31523 1 Linux 1 Linux Kernel 2026-04-28 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: ensure we're polling a polled queue A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.
CVE-2026-31516 1 Linux 1 Linux Kernel 2026-04-28 7.8 High
In the Linux kernel, the following vulnerability has been resolved: xfrm: prevent policy_hthresh.work from racing with netns teardown A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue. The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory. xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work. Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.
CVE-2023-37867 1 Yet Another Stars Rating Project 1 Yet Another Stars Rating 2026-04-28 3.7 Low
Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in YetAnotherStarsRating.Com YASR – Yet Another Star Rating Plugin for WordPress.This issue affects YASR – Yet Another Star Rating Plugin for WordPress: from n/a through 3.3.8.
CVE-2022-45809 1 Quicoto 1 Thumbs Rating 2026-04-28 5.3 Medium
Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Ricard Torres Thumbs Rating.This issue affects Thumbs Rating: from n/a through 5.0.0.
CVE-2026-31504 1 Linux 1 Linux Kernel 2026-04-28 7.8 High
In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race `packet_release()` has a race window where `NETDEV_UP` can re-register a socket into a fanout group's `arr[]` array. The re-registration is not cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout array. `packet_release()` does NOT zero `po->num` in its `bind_lock` section. After releasing `bind_lock`, `po->num` is still non-zero and `po->ifindex` still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)` that already found the socket in `sklist` can re-register the hook. For fanout sockets, this re-registration calls `__fanout_link(sk, po)` which adds the socket back into `f->arr[]` and increments `f->num_members`, but does NOT increment `f->sk_ref`. The fix sets `po->num` to zero in `packet_release` while `bind_lock` is held to prevent NETDEV_UP from linking, preventing the race window. This bug was found following an additional audit with Claude Code based on CVE-2025-38617.
CVE-2026-31618 1 Linux 1 Linux Kernel 2026-04-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: fbdev: tdfxfb: avoid divide-by-zero on FBIOPUT_VSCREENINFO Much like commit 19f953e74356 ("fbdev: fb_pm2fb: Avoid potential divide by zero error"), we also need to prevent that same crash from happening in the udlfb driver as it uses pixclock directly when dividing, which will crash.
CVE-2026-7217 1 Deepractice 1 Promptx 2026-04-28 5.3 Medium
A security vulnerability has been detected in Deepractice PromptX up to 2.4.0. The affected element is the function read_docx/read_xlsx/read_pptx/list_xlsx_sheets/read_pdf of the file packages/mcp-office/src/index.ts of the component Document File Handler. Such manipulation of the argument path leads to absolute path traversal. The attack can be executed remotely. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through an issue report but has not responded yet.
CVE-2025-31188 1 Apple 1 Macos 2026-04-28 7.8 High
A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5. An app may be able to bypass Privacy preferences.
CVE-2025-43244 1 Apple 4 Macos, Macos Sequoia, Macos Sonoma and 1 more 2026-04-28 9.8 Critical
A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to cause unexpected system termination.
CVE-2025-43364 1 Apple 3 Macos, Macos Sequoia, Macos Sonoma 2026-04-28 7.8 High
A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26.1. An app may be able to break out of its sandbox.
CVE-2026-6921 3 Google, Linux, Microsoft 4 Android, Chrome, Linux Kernel and 1 more 2026-04-28 8.3 High
Race in GPU in Google Chrome on Windows prior to 147.0.7727.117 allowed a remote attacker to potentially perform a sandbox escape via a crafted video file. (Chromium security severity: Medium)
CVE-2025-24094 1 Apple 1 Macos 2026-04-28 4 Medium
A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.3, macOS Sonoma 14.7.3, macOS Ventura 13.7.3. An app may be able to access user-sensitive data.
CVE-2025-43275 1 Apple 4 Macos, Macos Sequoia, Macos Sonoma and 1 more 2026-04-28 9.8 Critical
A race condition was addressed with additional validation. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to break out of its sandbox.
CVE-2025-43276 1 Apple 2 Macos, Macos Sequoia 2026-04-28 5.3 Medium
A logic error was addressed with improved error handling. This issue is fixed in macOS Sequoia 15.6. iCloud Private Relay may not activate when more than one user is logged in at the same time.
CVE-2025-43304 1 Apple 4 Macos, Macos Sequoia, Macos Sonoma and 1 more 2026-04-28 7 High
A race condition was addressed with improved state handling. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to gain root privileges.
CVE-2026-31473 1 Linux 1 Linux Kernel 2026-04-27 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports. We already serialize request queueing against STREAMON/OFF with req_queue_mutex. Extend that serialization to REQBUFS, and also take the same mutex in media_request_ioctl_reinit() so REINIT is in the same exclusion domain. This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.
CVE-2026-31474 1 Linux 1 Linux Kernel 2026-04-27 7.8 High
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix tx.buf use-after-free in isotp_sendmsg() isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize access to so->tx.buf. isotp_release() waits for ISOTP_IDLE via wait_event_interruptible() and then calls kfree(so->tx.buf). If a signal interrupts the wait_event_interruptible() inside close() while tx.state is ISOTP_SENDING, the loop exits early and release proceeds to force ISOTP_SHUTDOWN and continues to kfree(so->tx.buf) while sendmsg may still be reading so->tx.buf for the final CAN frame in isotp_fill_dataframe(). The so->tx.buf can be allocated once when the standard tx.buf length needs to be extended. Move the kfree() of this potentially extended tx.buf to sk_destruct time when either isotp_sendmsg() and isotp_release() are done.
CVE-2026-31578 1 Linux 1 Linux Kernel 2026-04-27 7.8 High
In the Linux kernel, the following vulnerability has been resolved: media: as102: fix to not free memory after the device is registered in as102_usb_probe() In as102_usb driver, the following race condition occurs: ``` CPU0 CPU1 as102_usb_probe() kzalloc(); // alloc as102_dev_t .... usb_register_dev(); fd = sys_open("/path/to/dev"); // open as102 fd .... usb_deregister_dev(); .... kfree(); // free as102_dev_t .... sys_close(fd); as102_release() // UAF!! as102_usb_release() kfree(); // DFB!! ``` When a USB character device registered with usb_register_dev() is later unregistered (via usb_deregister_dev() or disconnect), the device node is removed so new open() calls fail. However, file descriptors that are already open do not go away immediately: they remain valid until the last reference is dropped and the driver's .release() is invoked. In as102, as102_usb_probe() calls usb_register_dev() and then, on an error path, does usb_deregister_dev() and frees as102_dev_t right away. If userspace raced a successful open() before the deregistration, that open FD will later hit as102_release() --> as102_usb_release() and access or free as102_dev_t again, occur a race to use-after-free and double-free vuln. The fix is to never kfree(as102_dev_t) directly once usb_register_dev() has succeeded. After deregistration, defer freeing memory to .release(). In other words, let release() perform the last kfree when the final open FD is closed.