Export limit exceeded: 420915 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1943 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-6528 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| TLS protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 allows denial of service | ||||
| CVE-2026-6521 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| OpenFlow v5 protocol dissector infinite loops in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-6522 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| RPKI-Router protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-6523 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| GNW protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-5407 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| SMB2 protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-7375 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| UDS protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-6534 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| USB HID protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-6536 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| DLMS/COSEM protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 | ||||
| CVE-2026-6519 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| MBIM protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-6520 | 1 Wireshark | 1 Wireshark | 2026-05-01 | 5.5 Medium |
| OpenFlow v6 protocol dissector infinite loop in Wireshark 4.6.0 to 4.6.4 and 4.4.0 to 4.4.14 allows denial of service | ||||
| CVE-2026-31509 | 1 Linux | 1 Linux Kernel | 2026-04-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix circular locking dependency in nci_close_device nci_close_device() flushes rx_wq and tx_wq while holding req_lock. This causes a circular locking dependency because nci_rx_work() running on rx_wq can end up taking req_lock too: nci_rx_work -> nci_rx_data_packet -> nci_data_exchange_complete -> __sk_destruct -> rawsock_destruct -> nfc_deactivate_target -> nci_deactivate_target -> nci_request -> mutex_lock(&ndev->req_lock) Move the flush of rx_wq after req_lock has been released. This should safe (I think) because NCI_UP has already been cleared and the transport is closed, so the work will see it and return -ENETDOWN. NIPA has been hitting this running the nci selftest with a debug kernel on roughly 4% of the runs. | ||||
| CVE-2026-31472 | 1 Linux | 1 Linux Kernel | 2026-04-28 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: validate inner IPv4 header length in IPTFS payload Add validation of the inner IPv4 packet tot_len and ihl fields parsed from decrypted IPTFS payloads in __input_process_payload(). A crafted ESP packet containing an inner IPv4 header with tot_len=0 causes an infinite loop: iplen=0 leads to capturelen=min(0, remaining)=0, so the data offset never advances and the while(data < tail) loop never terminates, spinning forever in softirq context. Reject inner IPv4 packets where tot_len < ihl*4 or ihl*4 < sizeof(struct iphdr), which catches both the tot_len=0 case and malformed ihl values. The normal IP stack performs this validation in ip_rcv_core(), but IPTFS extracts and processes inner packets before they reach that layer. | ||||
| CVE-2026-41680 | 2 Marked Project, Markedjs | 2 Marked, Marked | 2026-04-28 | 7.5 High |
| Marked is a markdown parser and compiler. From 18.0.0 to 18.0.1, a critical Denial of Service (DoS) vulnerability exists in marked. By providing a specific 3-byte input sequence a tab, a vertical tab, and a newline (\x09\x0b\n)—an unauthenticated attacker can trigger an infinite recursion loop during parsing. This leads to unbounded memory allocation, causing the host Node.js application to crash via Memory Exhaustion (OOM). This vulnerability is fixed in 18.0.2. | ||||
| CVE-2026-41285 | 1 Openbsd | 1 Openbsd | 2026-04-28 | 4.3 Medium |
| In OpenBSD through 7.8, the slaacd and rad daemons have an infinite loop when they receive a crafted ICMPv6 Neighbor Discovery (ND) option (over a local network) with length zero, because of an "nd_opt_len * 8 - 2" expression with no preceding check for whether nd_opt_len is zero. | ||||
| CVE-2026-31552 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom before skb_push"), wl1271_tx_allocate() and with it wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails. However, in wlcore_tx_work_locked(), a return value of -EAGAIN from wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being full. This causes the code to flush the buffer, put the skb back at the head of the queue, and immediately retry the same skb in a tight while loop. Because wlcore_tx_work_locked() holds wl->mutex, and the retry happens immediately with GFP_ATOMIC, this will result in an infinite loop and a CPU soft lockup. Return -ENOMEM instead so the packet is dropped and the loop terminates. The problem was found by an experimental code review agent based on gemini-3.1-pro while reviewing backports into v6.18.y. | ||||
| CVE-2026-31558 | 1 Linux | 1 Linux Kernel | 2026-04-27 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Make kvm_get_vcpu_by_cpuid() more robust kvm_get_vcpu_by_cpuid() takes a cpuid parameter whose type is int, so cpuid can be negative. Let kvm_get_vcpu_by_cpuid() return NULL for this case so as to make it more robust. This fix an out-of-bounds access to kvm_arch::phyid_map::phys_map[]. | ||||
| CVE-2026-6985 | 1 Cesanta | 1 Mongoose | 2026-04-27 | 5.3 Medium |
| A weakness has been identified in Cesanta Mongoose up to 7.20. This vulnerability affects the function handle_opt of the file /src/net_builtin.c of the component TCP Option Handler. This manipulation of the argument optlen causes infinite loop. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 7.21 is able to resolve this issue. Upgrading the affected component is advised. VulDB has contacted the vendor early and they confirmed quickly, that this issue got fixed already. | ||||
| CVE-2026-28214 | 1 Firebirdsql | 1 Firebird | 2026-04-24 | 6.5 Medium |
| Firebird is an open-source relational database management system. In versions prior to 5.0.4, 4.0.7 and 3.0.14, the ClumpletReader::getClumpletSize() function can overflow the totalLength value when parsing a Wide type clumplet, causing an infinite loop. An authenticated user with INSERT privileges on any table can exploit this via a crafted Batch Parameter Block to cause a denial of service against the server. This issue has been fixed in versions 5.0.4, 4.0.7 and 3.0.14. | ||||
| CVE-2026-40347 | 2 Fastapiexpert, Kludex | 2 Python-multipart, Python-multipart | 2026-04-24 | 5.3 Medium |
| Python-Multipart is a streaming multipart parser for Python. Versions prior to 0.0.26 have a denial of service vulnerability when parsing crafted `multipart/form-data` requests with large preamble or epilogue sections. Upgrade to version 0.0.26 or later, which skips ahead to the next boundary candidate when processing leading CR/LF data and immediately discards epilogue data after the closing boundary. | ||||
| CVE-2026-23409 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: apparmor: fix differential encoding verification Differential encoding allows loops to be created if it is abused. To prevent this the unpack should verify that a diff-encode chain terminates. Unfortunately the differential encode verification had two bugs. 1. it conflated states that had gone through check and already been marked, with states that were currently being checked and marked. This means that loops in the current chain being verified are treated as a chain that has already been verified. 2. the order bailout on already checked states compared current chain check iterators j,k instead of using the outer loop iterator i. Meaning a step backwards in states in the current chain verification was being mistaken for moving to an already verified state. Move to a double mark scheme where already verified states get a different mark, than the current chain being kept. This enables us to also drop the backwards verification check that was the cause of the second error as any already verified state is already marked. | ||||