Export limit exceeded: 10905 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 15942 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15942 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23390 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow The dma_map_sg tracepoint can trigger a perf buffer overflow when tracing large scatter-gather lists. With devices like virtio-gpu creating large DRM buffers, nents can exceed 1000 entries, resulting in: phys_addrs: 1000 * 8 bytes = 8,000 bytes dma_addrs: 1000 * 8 bytes = 8,000 bytes lengths: 1000 * 4 bytes = 4,000 bytes Total: ~20,000 bytes This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing: WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405 perf buffer not large enough, wanted 24620, have 8192 Cap all three dynamic arrays at 128 entries using min() in the array size calculation. This ensures arrays are only as large as needed (up to the cap), avoiding unnecessary memory allocation for small operations while preventing overflow for large ones. The tracepoint now records the full nents/ents counts and a truncated flag so users can see when data has been capped. Changes in v2: - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from Steven Rostedt) - This allocates only what's needed up to the cap, avoiding waste for small operations Reviwed-by: Sean Anderson <sean.anderson@linux.dev> | ||||
| CVE-2025-9300 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 5.3 Medium |
| A vulnerability was found in saitoha libsixel up to 1.10.3. Affected by this issue is the function sixel_debug_print_palette of the file src/encoder.c of the component img2sixel. The manipulation results in stack-based buffer overflow. The attack must be initiated from a local position. The exploit has been made public and could be used. The patch is identified as 316c086e79d66b62c0c4bc66229ee894e4fdb7d1. Applying a patch is advised to resolve this issue. | ||||
| CVE-2021-40656 | 1 Libsixel | 1 Libsixel | 2026-04-24 | 8.8 High |
| libsixel before 1.10 is vulnerable to Buffer Overflow in libsixel/src/quant.c:867. | ||||
| CVE-2020-21050 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.5 Medium |
| Libsixel prior to v1.8.3 contains a stack buffer overflow in the function gif_process_raster at fromgif.c. | ||||
| CVE-2019-20024 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.5 Medium |
| A heap-based buffer overflow was discovered in image_buffer_resize in fromsixel.c in libsixel before 1.8.4. | ||||
| CVE-2019-20094 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 8.8 High |
| An issue was discovered in libsixel 1.8.4. There is a heap-based buffer overflow in the function gif_init_frame at fromgif.c. | ||||
| CVE-2019-20140 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 8.8 High |
| An issue was discovered in libsixel 1.8.4. There is a heap-based buffer overflow in the function gif_out_code at fromgif.c. | ||||
| CVE-2022-27044 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 8.8 High |
| libsixel 1.8.6 is affected by Buffer Overflow in libsixel/src/quant.c:876. | ||||
| CVE-2019-19635 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 9.8 Critical |
| An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function sixel_decode_raw_impl at fromsixel.c. | ||||
| CVE-2018-19762 | 1 Saitoha | 1 Libsixel | 2026-04-24 | N/A |
| There is a heap-based buffer overflow at fromsixel.c (function: image_buffer_resize) in libsixel 1.8.2 that will cause a denial of service or possibly unspecified other impact. | ||||
| CVE-2019-19638 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 9.8 Critical |
| An issue was discovered in libsixel 1.8.2. There is a heap-based buffer overflow in the function load_pnm at frompnm.c, due to an integer overflow. | ||||
| CVE-2020-21548 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 8.8 High |
| Libsixel 1.8.3 contains a heap-based buffer overflow in the sixel_encode_highcolor function in tosixel.c. | ||||
| CVE-2020-21547 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 8.8 High |
| Libsixel 1.8.2 contains a heap-based buffer overflow in the dither_func_fs function in tosixel.c. | ||||
| CVE-2020-21677 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.5 Medium |
| A heap-based buffer overflow in the sixel_encoder_output_without_macro function in encoder.c of Libsixel 1.8.4 allows attackers to cause a denial of service (DOS) via converting a crafted PNG file into Sixel format. | ||||
| CVE-2026-27879 | 1 Grafana | 1 Grafana | 2026-04-24 | 6.5 Medium |
| A resample query can be used to trigger out-of-memory crashes in Grafana. | ||||
| CVE-2026-23326 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xsk: Fix fragment node deletion to prevent buffer leak After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below. xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list. Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly. | ||||
| CVE-2026-23323 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (macsmc) Fix regressions in Apple Silicon SMC hwmon driver The recently added macsmc-hwmon driver contained several critical bugs in its sensor population logic and float conversion routines. Specifically: - The voltage sensor population loop used the wrong prefix ("volt-" instead of "voltage-") and incorrectly assigned sensors to the temperature sensor array (hwmon->temp.sensors) instead of the voltage sensor array (hwmon->volt.sensors). This would lead to out-of-bounds memory access or data corruption when both temperature and voltage sensors were present. - The float conversion in macsmc_hwmon_write_f32() had flawed exponent logic for values >= 2^24 and lacked masking for the mantissa, which could lead to incorrect values being written to the SMC. Fix these issues to ensure correct sensor registration and reliable manual fan control. Confirm that the reported overflow in FIELD_PREP is fixed by declaring macsmc_hwmon_write_f32() as __always_inline for a compile test. | ||||
| CVE-2026-30999 | 1 Ffmpeg | 1 Ffmpeg | 2026-04-23 | 7.5 High |
| A heap buffer overflow in the av_bprint_finalize() function of FFmpeg v8.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted input. | ||||
| CVE-2026-6067 | 1 Nasm | 2 Nasm, Netwide Assembler | 2026-04-23 | 7.5 High |
| A heap buffer overflow vulnerability exists in the Netwide Assembler (NASM) due to a lack of bounds checking in the obj_directive() function. This vulnerability can be exploited by a user assembling a malicious .asm file, potentially leading to heap memory corruption, denial of service (crash), and arbitrary code execution. | ||||
| CVE-2026-5450 | 2 Gnu, The Gnu C Library | 2 Glibc, Glibc | 2026-04-23 | 9.8 Critical |
| Calling the scanf family of functions with a %mc (malloc'd character match) in the GNU C Library version 2.7 to version 2.43 with a format width specifier with an explicit width greater than 1024 could result in a one byte heap buffer overflow. | ||||