Total
13631 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-23422 | 1 Linux | 1 Linux Kernel | 2026-04-24 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handler Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler") introduces a range check for if_id to avoid an out-of-bounds access. If an out-of-bounds if_id is detected, the interrupt status is not cleared. This may result in an interrupt storm. Clear the interrupt status after detecting an out-of-bounds if_id to avoid the problem. Found by an experimental AI code review agent at Google. | |||||
| CVE-2021-40656 | 1 Libsixel | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 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 | 4.3 MEDIUM | 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-20094 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 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-2020-21547 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 8.8 HIGH |
| Libsixel 1.8.2 contains a heap-based buffer overflow in the dither_func_fs function in tosixel.c. | |||||
| CVE-2019-19635 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 7.5 HIGH | 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-2020-21677 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 4.3 MEDIUM | 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-2022-27044 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 8.8 HIGH |
| libsixel 1.8.6 is affected by Buffer Overflow in libsixel/src/quant.c:876. | |||||
| CVE-2019-20140 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 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 | 7.5 HIGH | 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 | 6.8 MEDIUM | 8.8 HIGH |
| Libsixel 1.8.3 contains a heap-based buffer overflow in the sixel_encode_highcolor function in tosixel.c. | |||||
| CVE-2018-19762 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 6.8 MEDIUM | 7.8 HIGH |
| 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-20024 | 1 Saitoha | 1 Libsixel | 2026-04-24 | 4.3 MEDIUM | 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-23343 | 1 Linux | 1 Linux Kernel | 2026-04-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: xdp: produce a warning when calculated tailroom is negative Many ethernet drivers report xdp Rx queue frag size as being the same as DMA write size. However, the only user of this field, namely bpf_xdp_frags_increase_tail(), clearly expects a truesize. Such difference leads to unspecific memory corruption issues under certain circumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when running xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses all DMA-writable space in 2 buffers. This would be fine, if only rxq->frag_size was properly set to 4K, but value of 3K results in a negative tailroom, because there is a non-zero page offset. We are supposed to return -EINVAL and be done with it in such case, but due to tailroom being stored as an unsigned int, it is reported to be somewhere near UINT_MAX, resulting in a tail being grown, even if the requested offset is too much (it is around 2K in the abovementioned test). This later leads to all kinds of unspecific calltraces. [ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6 [ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4 [ 7340.338179] in libc.so.6[61c9d,7f4161aaf000+160000] [ 7340.339230] in xskxceiver[42b5,400000+69000] [ 7340.340300] likely on CPU 6 (core 0, socket 6) [ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe [ 7340.340888] likely on CPU 3 (core 0, socket 3) [ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7 [ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI [ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy) [ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 [ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80 [ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89 [ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202 [ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010 [ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff [ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0 [ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0 [ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500 [ 7340.418229] FS: 0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000 [ 7340.419489] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0 [ 7340.421237] PKRU: 55555554 [ 7340.421623] Call Trace: [ 7340.421987] <TASK> [ 7340.422309] ? softleaf_from_pte+0x77/0xa0 [ 7340.422855] swap_pte_batch+0xa7/0x290 [ 7340.423363] zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270 [ 7340.424102] zap_pte_range+0x281/0x580 [ 7340.424607] zap_pmd_range.isra.0+0xc9/0x240 [ 7340.425177] unmap_page_range+0x24d/0x420 [ 7340.425714] unmap_vmas+0xa1/0x180 [ 7340.426185] exit_mmap+0xe1/0x3b0 [ 7340.426644] __mmput+0x41/0x150 [ 7340.427098] exit_mm+0xb1/0x110 [ 7340.427539] do_exit+0x1b2/0x460 [ 7340.427992] do_group_exit+0x2d/0xc0 [ 7340.428477] get_signal+0x79d/0x7e0 [ 7340.428957] arch_do_signal_or_restart+0x34/0x100 [ 7340.429571] exit_to_user_mode_loop+0x8e/0x4c0 [ 7340.430159] do_syscall_64+0x188/ ---truncated--- | |||||
| CVE-2026-23326 | 1 Linux | 1 Linux Kernel | 2026-04-23 | N/A | 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 | N/A | 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-6067 | 1 Nasm | 1 Netwide Assembler | 2026-04-23 | N/A | 5.5 MEDIUM |
| 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-31789 | 1 Openssl | 1 Openssl | 2026-04-23 | N/A | 9.8 CRITICAL |
| Issue summary: Converting an excessively large OCTET STRING value to a hexadecimal string leads to a heap buffer overflow on 32 bit platforms. Impact summary: A heap buffer overflow may lead to a crash or possibly an attacker controlled code execution or other undefined behavior. If an attacker can supply a crafted X.509 certificate with an excessively large OCTET STRING value in extensions such as the Subject Key Identifier (SKID) or Authority Key Identifier (AKID) which are being converted to hex, the size of the buffer needed for the result is calculated as multiplication of the input length by 3. On 32 bit platforms, this multiplication may overflow resulting in the allocation of a smaller buffer and a heap buffer overflow. Applications and services that print or log contents of untrusted X.509 certificates are vulnerable to this issue. As the certificates would have to have sizes of over 1 Gigabyte, printing or logging such certificates is a fairly unlikely operation and only 32 bit platforms are affected, this issue was assigned Low severity. The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary. | |||||
| CVE-2026-5450 | 1 Gnu | 1 Glibc | 2026-04-23 | N/A | 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. | |||||
| CVE-2009-1532 | 1 Microsoft | 5 Internet Explorer, Windows Server 2003, Windows Server 2008 and 2 more | 2026-04-23 | 9.3 HIGH | 8.8 HIGH |
| Microsoft Internet Explorer 8 for Windows XP SP2 and SP3; 8 for Server 2003 SP2; 8 for Vista Gold, SP1, and SP2; and 8 for Server 2008 SP2 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code via "malformed row property references" that trigger an access of an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka "HTML Objects Memory Corruption Vulnerability" or "HTML Object Memory Corruption Vulnerability." | |||||