Export limit exceeded: 15317 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 29006 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 15317 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 15935 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (15935 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23361 | 1 Linux | 1 Linux Kernel | 2026-04-24 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap. If the PCI write loses the race with the ATU unmap, the write may corrupt host memory or cause IOMMU errors, e.g., these when running fio with a larger queue depth against nvmet-pci-epf: arm-smmu-v3 fc900000.iommu: 0x0000010000000010 arm-smmu-v3 fc900000.iommu: 0x0000020000000000 arm-smmu-v3 fc900000.iommu: 0x000000090000f040 arm-smmu-v3 fc900000.iommu: 0x0000000000000000 arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0 arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0 Flush the write by performing a readl() of the same address to ensure that the write has reached the destination before the ATU entry is unmapped. The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there it was solved by dedicating an outbound iATU only for MSI. We can't do the same for MSI-X because each vector can have a different msg_addr and the msg_addr may be changed while the vector is masked. [bhelgaas: commit log] | ||||
| 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-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-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-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-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-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-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-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-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-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-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-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-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. | ||||