Total
12562 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-31259 | 1 Apple | 1 Macos | 2025-05-27 | 7.8 High |
| The issue was addressed with improved input sanitization. This issue is fixed in macOS Sequoia 15.5. An app may be able to gain elevated privileges. | ||||
| CVE-2020-14797 | 5 Debian, Netapp, Opensuse and 2 more | 22 Debian Linux, 7-mode Transition Tool, Active Iq Unified Manager and 19 more | 2025-05-27 | 3.7 Low |
| Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N). | ||||
| CVE-2020-14621 | 8 Canonical, Debian, Fedoraproject and 5 more | 27 Ubuntu Linux, Debian Linux, Fedora and 24 more | 2025-05-27 | 5.3 Medium |
| Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JAXP). Supported versions that are affected are Java SE: 7u261, 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N). | ||||
| CVE-2024-29461 | 2 Atlassian, Projectfloodlight | 2 Floodlight Controller, Open Sdn Controller | 2025-05-27 | 6.3 Medium |
| An issue in Floodlight SDN OpenFlow Controller v.1.2 allows a remote attacker to cause a denial of service via the datapath id component. | ||||
| CVE-2023-48425 | 1 Google | 2 Chromecast, Chromecast Firmware | 2025-05-27 | 9.8 Critical |
| U-Boot vulnerability resulting in persistent Code Execution | ||||
| CVE-2021-27774 | 1 Hcltech | 1 Hcl Digital Experience | 2025-05-27 | 3.1 Low |
| User input included in error response, which could be used in a phishing attack. | ||||
| CVE-2025-41378 | 2025-05-27 | N/A | ||
| The SSID field is not parsed correctly and can be used to inject commands into the hostpad.conf file. This can be exploited by an attacker to extend his knowledge of the system and compromise other devices. The information is filtered by the logs function of the web panel. | ||||
| CVE-2025-24274 | 1 Apple | 1 Macos | 2025-05-27 | 7.8 High |
| An input validation issue was addressed by removing the vulnerable code. This issue is fixed in macOS Ventura 13.7.6, macOS Sequoia 15.5, macOS Sonoma 14.7.6. A malicious app may be able to gain root privileges. | ||||
| CVE-2025-30442 | 1 Apple | 1 Macos | 2025-05-27 | 7.8 High |
| The issue was addressed with improved input sanitization. This issue is fixed in macOS Sequoia 15.4, macOS Ventura 13.7.6, macOS Sonoma 14.7.6. An app may be able to gain elevated privileges. | ||||
| CVE-2025-31208 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-05-27 | 7.5 High |
| The issue was addressed with improved checks. This issue is fixed in watchOS 11.5, macOS Sonoma 14.7.6, tvOS 18.5, iPadOS 17.7.7, iOS 18.5 and iPadOS 18.5, macOS Sequoia 15.5, visionOS 2.5, macOS Ventura 13.7.6. Parsing a file may lead to an unexpected app termination. | ||||
| CVE-2024-36907 | 2025-05-26 | 5.5 Medium | ||
| This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. | ||||
| CVE-2025-38049 | 1 Linux | 1 Linux Kernel | 2025-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors Commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. This support missed that some platforms may not have these counters. This causes a NULL pointer dereference when creating a new control group as the array was not allocated by dom_data_init(). As this feature isn't necessary on platforms that don't have cache occupancy monitors, add this to the check that occurs when a new control group is allocated. | ||||
| CVE-2025-37798 | 1 Linux | 1 Linux Kernel | 2025-05-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog() After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). | ||||
| CVE-2025-37789 | 2025-05-26 | 6.1 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix nested key length validation in the set() action It's not safe to access nla_len(ovs_key) if the data is smaller than the netlink header. Check that the attribute is OK first. | ||||
| CVE-2025-37756 | 2025-05-26 | 3.3 Low | ||
| In the Linux kernel, the following vulnerability has been resolved: net: tls: explicitly disallow disconnect syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be _acked_. Disconnect is not commonly used, disallow it. The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237 | ||||
| CVE-2025-37747 | 2025-05-26 | 4.7 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: perf: Fix hang while freeing sigtrap event Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed: perf_event_overflow() task_work_add(perf_pending_task) fput() task_work_add(____fput()) task_work_run() ____fput() perf_release() perf_event_release_kernel() _free_event() perf_pending_task_sync() task_work_cancel() -> FAILED rcuwait_wait_event() Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event(). Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg: T1 T2 fd = perf_event_open(pid => T2->pid); fd = perf_event_open(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perf_event_overflow() perf_event_overflow() task_work_add(perf_pending_task) task_work_add(perf_pending_task) </IRQ> </IRQ> fput() fput() task_work_add(____fput()) task_work_add(____fput()) task_work_run() task_work_run() ____fput() ____fput() perf_release() perf_release() perf_event_release_kernel() perf_event_release_kernel() _free_event() _free_event() perf_pending_task_sync() perf_pending_task_sync() rcuwait_wait_event() rcuwait_wait_event() Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed. Some adjustments are necessary to make it work: * A child event might dereference its parent upon freeing. Care must be taken to release the parent last. * Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job. | ||||
| CVE-2025-23162 | 2025-05-26 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Don't try to trigger a full GT reset if VF VFs don't have access to the GDRST(0x941c) register that driver uses to reset a GT. Attempt to trigger a reset using debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset or due to a hang condition detected by the driver leads to: [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reset queued [ ] xe 0000:00:02.1: [drm] GT0: reset started [ ] ------------[ cut here ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Call Trace: [ ] <TASK> [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? exc_invalid_op+0x18/0x80 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? __mutex_unlock_slowpath+0x41/0x2e0 [ ] xe_mmio_write32+0x64/0x150 [xe] [ ] do_gt_reset+0x2f/0xa0 [xe] [ ] gt_reset_worker+0x14e/0x1e0 [xe] [ ] process_one_work+0x21c/0x740 [ ] worker_thread+0x1db/0x3c0 Fix that by sending H2G VF_RESET(0x5507) action instead. | ||||
| CVE-2025-22117 | 2025-05-26 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: ice: fix using untrusted value of pkt_len in ice_vc_fdir_parse_raw() Fix using the untrusted value of proto->raw.pkt_len in function ice_vc_fdir_parse_raw() by verifying if it does not exceed the VIRTCHNL_MAX_SIZE_RAW_PACKET value. | ||||
| CVE-2025-22057 | 2025-05-26 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: net: decrease cached dst counters in dst_release Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too. | ||||
| CVE-2025-22021 | 2025-05-26 | 5.5 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: socket: Lookup orig tuple for IPv6 SNAT nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent. However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this conntrack lookup, making xt_socket fail to match on the socket when the packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6. IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on `-m socket --transparent` and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup. | ||||