Export limit exceeded: 348725 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (348725 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-43270 | 1 Linux | 1 Linux Kernel | 2026-05-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: media: mtk-mdp: Fix a reference leak bug in mtk_mdp_remove() In mtk_mdp_probe(), vpu_get_plat_device() increases the reference count of the returned platform device. Add platform_device_put() to prevent reference leak. | ||||
| CVE-2026-43275 | 1 Linux | 1 Linux Kernel | 2026-05-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Flush exception handling work when RPM level is zero Ensure that the exception event handling work is explicitly flushed during suspend when the runtime power management level is set to UFS_PM_LVL_0. When the RPM level is zero, the device power mode and link state both remain active. Previously, the UFS core driver bypassed flushing exception event handling jobs in this configuration. This created a race condition where the driver could attempt to access the host controller to handle an exception after the system had already entered a deep power-down state, resulting in a system crash. Explicitly flush this work and disable auto BKOPs before the suspend callback proceeds. This guarantees that pending exception tasks complete and prevents illegal hardware access during the power-down sequence. | ||||
| CVE-2026-43192 | 1 Linux | 1 Linux Kernel | 2026-05-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: dm mpath: Add missing dm_put_device when failing to get scsi dh name When commit fd81bc5cca8f ("scsi: device_handler: Return error pointer in scsi_dh_attached_handler_name()") added code to fail parsing the path if scsi_dh_attached_handler_name() failed with -ENOMEM, it didn't clean up the reference to the path device that had just been taken. Fix this, and steamline the error paths of parse_path() a little. | ||||
| CVE-2026-35091 | 2 Corosync, Redhat | 10 Corosync, Enterprise Linux, Enterprise Linux Eus and 7 more | 2026-05-06 | 8.2 High |
| A flaw was found in Corosync. A remote unauthenticated attacker can exploit a wrong return value vulnerability in the Corosync membership commit token sanity check by sending a specially crafted User Datagram Protocol (UDP) packet. This can lead to an out-of-bounds read, causing a denial of service (DoS) and potentially disclosing limited memory contents. This vulnerability affects Corosync when running in totemudp/totemudpu mode, which is the default configuration. | ||||
| CVE-2026-35092 | 2 Corosync, Redhat | 10 Corosync, Enterprise Linux, Enterprise Linux Eus and 7 more | 2026-05-06 | 7.5 High |
| A flaw was found in Corosync. An integer overflow vulnerability in Corosync's join message sanity validation allows a remote, unauthenticated attacker to send crafted User Datagram Protocol (UDP) packets. This can cause the service to crash, leading to a denial of service. This vulnerability specifically affects Corosync deployments configured to use totemudp/totemudpu mode. | ||||
| CVE-2026-7572 | 1 Velocidex | 1 Velociraptor | 2026-05-06 | 4.4 Medium |
| An off-by-one error (CWE-193) in the ConsumeUnit16Array and ConsumeUnit64Array functions in Velocidex Velociraptor before version 0.76.5 on Windows and Linux allows a local attacker to cause a Denial of Service (DoS) via a process crash by providing a specially crafted .evtx file to the parse_evtx VQL plugin. | ||||
| CVE-2026-42519 | 2 Jenkins, Jenkins Project | 2 Script Security, Jenkins Script Security Plugin | 2026-05-06 | 4.3 Medium |
| A missing permission check in Jenkins Script Security Plugin 1399.ve6a_66547f6e1 and earlier allows attackers with Overall/Read permission to enumerate pending and approved Script Security classpaths. | ||||
| CVE-2026-42520 | 2 Jenkins, Jenkins Project | 2 Credentials Binding, Jenkins Credentials Binding Plugin | 2026-05-06 | 7.5 High |
| Jenkins Credentials Binding Plugin 719.v80e905ef14eb_ and earlier does not sanitize file names for file and zip file credentials, allowing attackers able to provide credentials to a job to write files to arbitrary locations on the node filesystem, which can lead to remote code execution if Jenkins is configured to allow a low-privileged user to configure file or zip file credentials used for a job running on the built-in node. | ||||
| CVE-2026-43181 | 1 Linux | 1 Linux Kernel | 2026-05-06 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gpio: sysfs: fix chip removal with GPIOs exported over sysfs Currently if we export a GPIO over sysfs and unbind the parent GPIO controller, the exported attribute will remain under /sys/class/gpio because once we remove the parent device, we can no longer associate the descriptor with it in gpiod_unexport() and never drop the final reference. Rework the teardown code: provide an unlocked variant of gpiod_unexport() and remove all exported GPIOs with the sysfs_lock taken before unregistering the parent device itself. This is done to prevent any new exports happening before we unregister the device completely. | ||||
| CVE-2026-43189 | 1 Linux | 1 Linux Kernel | 2026-05-06 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: media: v4l2-async: Fix error handling on steps after finding a match Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches. Fix these specific issues: - If v4l2_async_match_notify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2_async_match_notify(). - The async connection's sd field was only set after creating ancillary links in v4l2_async_match_notify(). It was however dereferenced in v4l2_async_unbind_subdev_one(), which was called on error path of v4l2_async_match_notify() failure. | ||||
| CVE-2026-43193 | 1 Linux | 1 Linux Kernel | 2026-05-06 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfs4_file refcount leak in nfsd_get_dir_deleg() Claude pointed out that there is a nfs4_file refcount leak in nfsd_get_dir_deleg(). Ensure that the reference to "fp" is released before returning. | ||||
| CVE-2026-43194 | 1 Linux | 1 Linux Kernel | 2026-05-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link). | ||||
| CVE-2026-21661 | 1 Johnsoncontrols | 1 Ac2000 | 2026-05-06 | N/A |
| Uncontrolled Search Path Element vulnerability in JohnsonControls AC2000 on Windows allows Leveraging/Manipulating Configuration File Search Paths. This issue affects AC2000: from 10.6 before release 10, from 11.0 before release 9, from 12 before release 3. | ||||
| CVE-2026-42521 | 2 Jenkins, Jenkins Project | 2 Matrix Authorization Strategy, Jenkins Matrix Authorization Strategy Plugin | 2026-05-06 | 6.5 Medium |
| Jenkins Matrix Authorization Strategy Plugin 2.0-beta-1 through 3.2.9 (both inclusive) invokes parameterless constructors of classes specified in configuration when deserializing inheritance strategies, without restricting the classes that can be instantiated, allowing attackers with Item/Configure permission to instantiate arbitrary types, which may lead to information disclosure or other impacts depending on the classes available on the classpath. | ||||
| CVE-2026-42522 | 2 Jenkins, Jenkins Project | 2 Github Branch Source, Jenkins Github Branch Source Plugin | 2026-05-06 | 4.3 Medium |
| A missing permission check in Jenkins GitHub Branch Source Plugin 1967.vdea_d580c1a_b_a_ and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL with attacker-specified GitHub App credentials. | ||||
| CVE-2026-7573 | 1 Velocidex | 1 Velociraptor | 2026-05-06 | 5 Medium |
| An authorization bypass (CWE-639) in the GetUserRoles gRPC API endpoint in Velocidex Velociraptor below version 0.76.5 allows any authenticated low-privilege user to retrieve the complete ACL policy (roles and permissions) for any user across all organizations by supplying targeted Name and Org parameters via a network request. | ||||
| CVE-2026-6788 | 1 Watchguard | 1 Single Watchguard Agent | 2026-05-06 | N/A |
| Uncontrolled Search Path Element vulnerability in WatchGuard Agent on Windows allows Using Malicious Files.This issue affects WatchGuard Agent before 1.25.03.0000. | ||||
| CVE-2026-6787 | 1 Watchguard | 1 Single Watchguard Agent | 2026-05-06 | N/A |
| Use of Hard-coded Cryptographic Key vulnerability in WatchGuard Agent on Windows allows Inclusion of Code in Existing Process.This issue affects WatchGuard Agent: before 1.25.03.0000. | ||||
| CVE-2026-41288 | 1 Watchguard | 1 Single Watchguard Agent | 2026-05-06 | N/A |
| Incorrect permission assignment for a resource in the patch management component of the WatchGuard Agent on Windows allows an authenticated local user to elevate their privileges to NT AUTHORITY\\SYSTEM. | ||||
| CVE-2026-41286 | 1 Watchguard Technologies | 1 Single Watchguard Agent | 2026-05-06 | N/A |
| Stack-based Buffer Overflow vulnerability in the WatchGuard Agent discovery service on Windows allows Overflow Buffers. An unauthenticated attacker on the same local network could exploit this vulnerability to crash the agent service. | ||||