Export limit exceeded: 16359 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 383540 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 24972 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (24972 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-71201 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early read unlock of page with EOF in middle The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet: 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0 ... netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3 ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0 The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap. The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after. Fix this by changing the end check to always be the end of the folio and never the end of the file. In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros. This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like: xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case. AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread. | ||||
| CVE-2025-67721 | 1 Airlift | 1 Aircompressor | 2026-03-17 | 7.5 High |
| Aircompressor is a library with ports of the Snappy, LZO, LZ4, and Zstandard compression algorithms to Java. In versions 3.3 and below, incorrect handling of malformed data in Java-based decompressor implementations for Snappy and LZ4 allow remote attackers to read previous buffer contents via crafted compressed input. With certain crafted compressed inputs, elements from the output buffer can end up in the uncompressed output, potentially leaking sensitive data. This is relevant for applications that reuse the same output buffer to uncompress multiple inputs. This can be the case of a web server that allocates a fix-sized buffer for performance purposes. There is similar vulnerability in GHSA-cmp6-m4wj-q63q. This issue is fixed in version 3.4. | ||||
| CVE-2025-60690 | 1 Linksys | 2 E1200, E1200 Firmware | 2026-03-17 | 8.8 High |
| A stack-based buffer overflow exists in the get_merge_ipaddr function of the httpd binary on Linksys E1200 v2 routers (Firmware E1200_v2.0.11.001_us.tar.gz). The function concatenates up to four user-supplied CGI parameters matching <parameter>_0~3 into a fixed-size buffer (a2) without bounds checking. Remote attackers can exploit this vulnerability via specially crafted HTTP requests to execute arbitrary code or cause denial of service without authentication. | ||||
| CVE-2023-37329 | 1 Gstreamer | 1 Gstreamer | 2026-03-17 | 8.8 High |
| GStreamer SRT File Parsing Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the parsing of SRT subtitle files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-20968. | ||||
| CVE-2017-5846 | 1 Gstreamer | 1 Gstreamer | 2026-03-17 | N/A |
| The gst_asf_demux_process_ext_stream_props function in gst/asfdemux/gstasfdemux.c in gst-plugins-ugly in GStreamer before 1.10.3 allows remote attackers to cause a denial of service (invalid memory read and crash) via vectors related to the number of languages in a video file. | ||||
| CVE-2024-47602 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 7.5 High |
| GStreamer is a library for constructing graphs of media-handling components. A null pointer dereference vulnerability has been discovered in the gst_matroska_demux_add_wvpk_header function within matroska-demux.c. This function does not properly check the validity of the stream->codec_priv pointer in the following code. If stream->codec_priv is NULL, the call to GST_READ_UINT16_LE will attempt to dereference a null pointer, leading to a crash of the application. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2016-10199 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | N/A |
| The qtdemux_tag_add_str_full function in gst/isomp4/qtdemux.c in gst-plugins-good in GStreamer before 1.10.3 allows remote attackers to cause a denial of service (out-of-bounds read and crash) via a crafted tag value. | ||||
| CVE-2024-47776 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 9.1 Critical |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been discovered in gst_wavparse_cue_chunk within gstwavparse.c. The vulnerability happens due to a discrepancy between the size of the data buffer and the size value provided to the function. This mismatch causes the comparison if (size < 4 + ncues * 24) to fail in some cases, allowing the subsequent loop to access beyond the bounds of the data buffer. The root cause of this discrepancy stems from a miscalculation when clipping the chunk size based on upstream data size. This vulnerability allows reading beyond the bounds of the data buffer, potentially leading to a crash (denial of service) or the leak of sensitive data. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2024-47777 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 9.1 Critical |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been identified in the gst_wavparse_smpl_chunk function within gstwavparse.c. This function attempts to read 4 bytes from the data + 12 offset without checking if the size of the data buffer is sufficient. If the buffer is too small, the function reads beyond its bounds. This vulnerability may result in reading 4 bytes out of the boundaries of the data buffer. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2024-47774 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 9.1 Critical |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been identified in the gst_avi_subtitle_parse_gab2_chunk function within gstavisubtitle.c. The function reads the name_length value directly from the input file without checking it properly. Then, the a condition, does not properly handle cases where name_length is greater than 0xFFFFFFFF - 17, causing an integer overflow. In such scenario, the function attempts to access memory beyond the buffer leading to an OOB-read. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2025-47806 | 1 Gstreamer | 1 Gstreamer | 2026-03-17 | 5.6 Medium |
| In GStreamer through 1.26.1, the subparse plugin's parse_subrip_time function may write data past the bounds of a stack buffer, leading to a crash. | ||||
| CVE-2016-10198 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | N/A |
| The gst_aac_parse_sink_setcaps function in gst/audioparsers/gstaacparse.c in gst-plugins-good in GStreamer before 1.10.3 allows remote attackers to cause a denial of service (invalid memory read and crash) via a crafted audio file. | ||||
| CVE-2024-47596 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 7.5 High |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read has been discovered in the qtdemux_parse_svq3_stsd_data function within qtdemux.c. In the FOURCC_SMI_ case, seqh_size is read from the input file without proper validation. If seqh_size is greater than the remaining size of the data buffer, it can lead to an OOB-read in the following call to gst_buffer_fill, which internally uses memcpy. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2024-47778 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 7.5 High |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been discovered in gst_wavparse_adtl_chunk within gstwavparse.c. This vulnerability arises due to insufficient validation of the size parameter, which can exceed the bounds of the data buffer. As a result, an OOB read occurs in the following while loop. This vulnerability can result in reading up to 4GB of process memory or potentially causing a segmentation fault (SEGV) when accessing invalid memory. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2017-5841 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | N/A |
| The gst_avi_demux_parse_ncdt function in gst/avi/gstavidemux.c in gst-plugins-good in GStreamer before 1.10.3 allows remote attackers to cause a denial of service (out-of-bounds heap read) via vectors involving ncdt tags. | ||||
| CVE-2024-47775 | 2 Gstreamer, Redhat | 2 Gstreamer, Enterprise Linux | 2026-03-17 | 9.1 Critical |
| GStreamer is a library for constructing graphs of media-handling components. An OOB-read vulnerability has been found in the parse_ds64 function within gstwavparse.c. The parse_ds64 function does not check that the buffer buf contains sufficient data before attempting to read from it, doing multiple GST_READ_UINT32_LE operations without performing boundary checks. This can lead to an OOB-read when buf is smaller than expected. This vulnerability allows reading beyond the bounds of the data buffer, potentially leading to a crash (denial of service) or the leak of sensitive data. This vulnerability is fixed in 1.24.10. | ||||
| CVE-2022-1920 | 3 Debian, Gstreamer, Redhat | 3 Debian Linux, Gstreamer, Enterprise Linux | 2026-03-17 | 7.8 High |
| Integer overflow in matroskademux element in gst_matroska_demux_add_wvpk_header function which allows a heap overwrite while parsing matroska files. Potential for arbitrary code execution through heap overwrite. | ||||
| CVE-2022-1925 | 3 Debian, Gstreamer, Redhat | 3 Debian Linux, Gstreamer, Enterprise Linux | 2026-03-17 | 7.8 High |
| DOS / potential heap overwrite in mkv demuxing using HEADERSTRIP decompression. Integer overflow in matroskaparse element in gst_matroska_decompress_data function which causes a heap overflow. Due to restrictions on chunk sizes in the matroskademux element, the overflow can't be triggered, however the matroskaparse element has no size checks. | ||||
| CVE-2022-2122 | 3 Debian, Gstreamer, Redhat | 3 Debian Linux, Gstreamer, Enterprise Linux | 2026-03-17 | 7.8 High |
| DOS / potential heap overwrite in qtdemux using zlib decompression. Integer overflow in qtdemux element in qtdemux_inflate function which causes a segfault, or could cause a heap overwrite, depending on libc and OS. Depending on the libc used, and the underlying OS capabilities, it could be just a segfault or a heap overwrite. | ||||
| CVE-2022-1924 | 3 Debian, Gstreamer, Redhat | 3 Debian Linux, Gstreamer, Enterprise Linux | 2026-03-17 | 7.8 High |
| DOS / potential heap overwrite in mkv demuxing using lzo decompression. Integer overflow in matroskademux element in lzo decompression function which causes a segfault, or could cause a heap overwrite, depending on libc and OS. Depending on the libc used, and the underlying OS capabilities, it could be just a segfault or a heap overwrite. If the libc uses mmap for large chunks, and the OS supports mmap, then it is just a segfault (because the realloc before the integer overflow will use mremap to reduce the size of the chunk, and it will start to write to unmapped memory). However, if using a libc implementation that does not use mmap, or if the OS does not support mmap while using libc, then this could result in a heap overwrite. | ||||