Export limit exceeded: 19877 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (19877 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-53133 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser() When the buffer length of the recvmsg system call is 0, we got the flollowing soft lockup problem: watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149] CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:remove_wait_queue+0xb/0xc0 Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20 RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768 RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040 RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7 R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800 R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0 FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc The logic in tcp_bpf_recvmsg_parser is as follows: msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; } In this case, "copied" always is 0, the infinite loop occurs. According to the Linux system call man page, 0 should be returned in this case. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directly return. Also modify several other functions with the same problem. | ||||
| CVE-2022-49822 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cifs: Fix connections leak when tlink setup failed If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup. | ||||
| CVE-2026-23254 | 1 Linux | 1 Linux Kernel | 2026-06-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: gro: fix outer network offset The udp GRO complete stage assumes that all the packets inserted the RX have the `encapsulation` flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup. Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing. Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete(). | ||||
| CVE-2026-0826 | 1 Hp Inc. | 3 Poly Trio 8300, Poly Trio 8500, Poly Trio 8800 | 2026-06-01 | N/A |
| In certain scenarios when the admin has enabled Interactive Connectivity Establishment (ICE), a buffer overflow could enable remote code execution on Poly Voice products on the Linux platform. | ||||
| CVE-2026-42399 | 1 Elastic | 1 Kibana | 2026-06-01 | 6.5 Medium |
| Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated low-privileged user can cause Kibana to consume exponentially increasing amounts of memory by submitting a specially crafted Timelion visualization expression containing deeply chained function calls. The resulting data structure grows without bound, exhausting available memory and causing the Kibana service to crash and become unavailable to all users. | ||||
| CVE-2026-42400 | 1 Elastic | 1 Kibana | 2026-06-01 | 6.5 Medium |
| Uncontrolled Resource Consumption (CWE-400) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user can send a specially crafted compressed request payload that is processed prior to authorization checks, causing excessive memory and CPU resource consumption that can result in a Kibana instance becoming unresponsive or crashing. | ||||
| CVE-2024-12144 | 2026-06-01 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Finder Fire Safety Finder ERP/CRM (Old System) allows SQL Injection. This issue affects Finder ERP/CRM (Old System): before 18.12.2024. | ||||
| CVE-2024-12146 | 2026-06-01 | 7.5 High | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Finder Fire Safety Finder ERP/CRM (New System) allows SQL Injection. This issue affects Finder ERP/CRM (New System): before 18.12.2024. | ||||
| CVE-2024-12914 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 4.3 Medium |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Akınsoft QR Menü allows Cross-Site Scripting (XSS). This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12924 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 6.3 Medium |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in Akınsoft QR Menü allows Forceful Browsing, Phishing. This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12925 | 1 Akinsoft | 1 Qr Menu | 2026-06-01 | 7.3 High |
| Improper Validation of Certificate with Host Mismatch vulnerability in Akınsoft QR Menü allows HTTP Response Splitting. This issue affects QR Menü: from s1.05.05 before v1.05.12. | ||||
| CVE-2024-12970 | 2026-06-01 | 3.9 Low | ||
| Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in TUBITAK BILGEM Pardus OS My Computer allows OS Command Injection. This issue affects Pardus OS My Computer: before 0.7.2. | ||||
| CVE-2024-12972 | 1 Akinsoft | 1 Octocloud | 2026-06-01 | 4.3 Medium |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Akinsoft OctoCloud allows Cross-Site Scripting (XSS). This issue affects OctoCloud: from s1.09.01 before v1.11.01. | ||||
| CVE-2024-12973 | 1 Akinsoft | 1 Octocloud | 2026-06-01 | 4.7 Medium |
| Origin Validation Error vulnerability in Akinsoft OctoCloud allows HTTP Response Splitting, CAPEC - 87 - Forceful Browsing. This issue affects OctoCloud: from s1.09.01 before v1.11.01. | ||||
| CVE-2024-12974 | 1 Akinsoft | 1 Prokuaför | 2026-06-01 | 4.3 Medium |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Akinsoft ProKuaför allows Cross-Site Scripting (XSS). This issue affects ProKuaför: from s1.02.07 before v1.02.08. | ||||
| CVE-2024-13147 | 2026-06-01 | 9.8 Critical | ||
| Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Merkur Software B2B Login Panel allows SQL Injection. This issue affects B2B Login Panel: before 15.01.2025. | ||||
| CVE-2025-11234 | 1 Redhat | 4 Enterprise Linux, Openshift, Rhel E4s and 1 more | 2026-06-01 | 7.5 High |
| A flaw was found in QEMU. If the QIOChannelWebsock object is freed while it is waiting to complete a handshake, a GSource is leaked. This can lead to the callback firing later on and triggering a use-after-free in the use of the channel. This can be abused by a malicious client with network access to the VNC WebSocket port to cause a denial of service during the WebSocket handshake prior to the VNC client authentication. | ||||
| CVE-2026-45292 | 1 Opentelemetry | 3 Opentelemetry-java, Opentelemetry.api, Opentelemetry.extensions.propagators | 2026-05-30 | 5.3 Medium |
| opentelemetry-java is the Java implementation of the OpenTelemetry API for recording telemetry, and SDK for managing telemetry recorded by the API. Prior to 1.62.0, a vulnerability affects the baggage propagation implementation in opentelemetry-api and opentelemetry-extension-trace-propagators. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. This vulnerability is fixed in 1.62.0. | ||||
| CVE-2026-46384 | 1 Iskorotkov | 1 Avro | 2026-05-30 | 7.5 High |
| iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0. | ||||
| CVE-2026-43503 | 1 Linux | 1 Linux Kernel | 2026-05-30 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() / xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently. The same omission exists in skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker. | ||||