Export limit exceeded: 351254 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1364 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2017-11338 | 1 Exiv2 | 1 Exiv2 | 2025-04-20 | N/A |
| There is an infinite loop in the Exiv2::Image::printIFDStructure function of image.cpp in Exiv2 0.26. A crafted input will lead to a remote denial of service attack. | ||||
| CVE-2017-11360 | 1 Imagemagick | 1 Imagemagick | 2025-04-20 | N/A |
| The ReadRLEImage function in coders\rle.c in ImageMagick 7.0.6-1 has a large loop vulnerability via a crafted rle file that triggers a huge number_pixels value. | ||||
| CVE-2017-11406 | 2 Debian, Wireshark | 2 Debian Linux, Wireshark | 2025-04-20 | N/A |
| In Wireshark 2.2.0 to 2.2.7 and 2.0.0 to 2.0.13, the DOCSIS dissector could go into an infinite loop. This was addressed in plugins/docsis/packet-docsis.c by rejecting invalid Frame Control parameter values. | ||||
| CVE-2017-11409 | 2 Debian, Wireshark | 2 Debian Linux, Wireshark | 2025-04-20 | N/A |
| In Wireshark 2.0.0 to 2.0.13, the GPRS LLC dissector could go into a large loop. This was addressed in epan/dissectors/packet-gprs-llc.c by using a different integer data type. | ||||
| CVE-2017-11410 | 1 Wireshark | 1 Wireshark | 2025-04-20 | N/A |
| In Wireshark through 2.0.13 and 2.2.x through 2.2.7, the WBXML dissector could go into an infinite loop, triggered by packet injection or a malformed capture file. This was addressed in epan/dissectors/packet-wbxml.c by adding validation of the relationships between indexes and lengths. NOTE: this vulnerability exists because of an incomplete fix for CVE-2017-7702. | ||||
| CVE-2017-11446 | 1 Imagemagick | 1 Imagemagick | 2025-04-20 | N/A |
| The ReadPESImage function in coders\pes.c in ImageMagick 7.0.6-1 has an infinite loop vulnerability that can cause CPU exhaustion via a crafted PES file. | ||||
| CVE-2017-11478 | 1 Imagemagick | 1 Imagemagick | 2025-04-20 | N/A |
| The ReadOneDJVUImage function in coders/djvu.c in ImageMagick through 6.9.9-0 and 7.x through 7.0.6-1 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a malformed DJVU image. | ||||
| CVE-2017-11505 | 1 Imagemagick | 1 Imagemagick | 2025-04-20 | N/A |
| The ReadOneJNGImage function in coders/png.c in ImageMagick through 6.9.9-0 and 7.x through 7.0.6-1 allows remote attackers to cause a denial of service (large loop and CPU consumption) via a malformed JNG file. | ||||
| CVE-2017-11523 | 1 Imagemagick | 1 Imagemagick | 2025-04-20 | N/A |
| The ReadTXTImage function in coders/txt.c in ImageMagick through 6.9.9-0 and 7.x through 7.0.6-1 allows remote attackers to cause a denial of service (infinite loop) via a crafted file, because the end-of-file condition is not considered. | ||||
| CVE-2017-11549 | 1 Timidity\+\+ Project | 1 Timidity\+\+ | 2025-04-20 | N/A |
| The play_midi function in playmidi.c in TiMidity++ 2.14.0 allows remote attackers to cause a denial of service (large loop and CPU consumption) via a crafted mid file. NOTE: CPU consumption might be relevant when using the --background option. | ||||
| CVE-2017-12989 | 2 Redhat, Tcpdump | 2 Enterprise Linux, Tcpdump | 2025-04-20 | N/A |
| The RESP parser in tcpdump before 4.9.2 could enter an infinite loop due to a bug in print-resp.c:resp_get_length(). | ||||
| CVE-2017-9461 | 3 Debian, Redhat, Samba | 10 Debian Linux, Enterprise Linux, Enterprise Linux Desktop and 7 more | 2025-04-20 | N/A |
| smbd in Samba before 4.4.10 and 4.5.x before 4.5.6 has a denial of service vulnerability (fd_open_atomic infinite loop with high CPU usage and memory consumption) due to wrongly handling dangling symlinks. | ||||
| CVE-2017-14054 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In libavformat/rmdec.c in FFmpeg 3.3.3, a DoS in ivr_read_header() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted IVR file, which claims a large "len" field in the header but does not contain sufficient backing data, is provided, the first type==4 loop would consume huge CPU resources, since there is no EOF check inside the loop. | ||||
| CVE-2017-14055 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In libavformat/mvdec.c in FFmpeg 3.3.3, a DoS in mv_read_header() due to lack of an EOF (End of File) check might cause huge CPU and memory consumption. When a crafted MV file, which claims a large "nb_frames" field in the header but does not contain sufficient backing data, is provided, the loop over the frames would consume huge CPU and memory resources, since there is no EOF check inside the loop. | ||||
| CVE-2017-14056 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In libavformat/rl2.c in FFmpeg 3.3.3, a DoS in rl2_read_header() due to lack of an EOF (End of File) check might cause huge CPU and memory consumption. When a crafted RL2 file, which claims a large "frame_count" field in the header but does not contain sufficient backing data, is provided, the loops (for offset and size tables) would consume huge CPU and memory resources, since there is no EOF check inside these loops. | ||||
| CVE-2017-14057 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In FFmpeg 3.3.3, a DoS in asf_read_marker() due to lack of an EOF (End of File) check might cause huge CPU and memory consumption. When a crafted ASF file, which claims a large "name_len" or "count" field in the header but does not contain sufficient backing data, is provided, the loops over the name and markers would consume huge CPU and memory resources, since there is no EOF check inside these loops. | ||||
| CVE-2017-14058 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In FFmpeg 2.4 and 3.3.3, the read_data function in libavformat/hls.c does not restrict reload attempts for an insufficient list, which allows remote attackers to cause a denial of service (infinite loop). | ||||
| CVE-2017-14059 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In FFmpeg 3.3.3, a DoS in cine_read_header() due to lack of an EOF check might cause huge CPU and memory consumption. When a crafted CINE file, which claims a large "duration" field in the header but does not contain sufficient backing data, is provided, the image-offset parsing loop would consume huge CPU and memory resources, since there is no EOF check inside the loop. | ||||
| CVE-2017-14170 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, a DoS in mxf_read_index_entry_array() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted MXF file, which claims a large "nb_index_entries" field in the header but does not contain sufficient backing data, is provided, the loop would consume huge CPU resources, since there is no EOF check inside the loop. Moreover, this big loop can be invoked multiple times if there is more than one applicable data segment in the crafted MXF file. | ||||
| CVE-2017-14171 | 1 Ffmpeg | 1 Ffmpeg | 2025-04-20 | N/A |
| In libavformat/nsvdec.c in FFmpeg 2.4 and 3.3.3, a DoS in nsv_parse_NSVf_header() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted NSV file, which claims a large "table_entries_used" field in the header but does not contain sufficient backing data, is provided, the loop over 'table_entries_used' would consume huge CPU resources, since there is no EOF check inside the loop. | ||||