Search vulnerabilities

Results 365

Export CSV
CVE-2026-22593

EVerest has off-by-one stack buffer overflow in IsoMux certificate filename parsing

EVerest is an EV charging software stack. Prior to version 2026.02.0, an off-by-one check in IsoMux certificate filename handling causes a stack-based buffer overflow when a filename length equals `MAX_FILE_NAME_LENGTH` (100). A crafted filename in the certificate directory can overflow `file_names[idx]`, corrupting stack state and enabling potential code execution. Version 2026.02.0 contains a patch.

CVSS 3.1 · 8.4 High EPSS < 1% KEV · Not listed
CVE-2026-31963

HTSlib CRAM reader has heap buffer overflow due to improper validation of input

HTSlib is a library for reading and writing bioinformatics file formats. CRAM is a compressed format which stores DNA sequence alignment data. As one method of removing redundant data, CRAM uses reference-based compression so that instead of storing the full sequence for each alignment record it stores a location in an external reference sequence along with a list of differences to the reference at that location as a sequence of "features". When decoding these features, an out-by-one error in a test for CRAM features that appear beyond the extent of the CRAM record sequence could result in an invalid write of one attacker-controlled byte beyond the end of a heap buffer. Exploiting this bug causes a heap buffer overflow. If a user opens a file crafted to exploit this issue, it could lead to the program crashing, or overwriting of data and heap structures in ways not expected by the program. It may be possible to use this to obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no workaround for this issue.

CVSS 4.0 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-28520

arduino-TuyaOpen WiFiMulti Single-Byte Buffer Overflow Remote Code Execution

arduino-TuyaOpen before version 1.2.1 contains a single-byte buffer overflow vulnerability in the WiFiMulti component. When the victim's smart hardware connects to an attacker-controlled AP hotspot, the attacker can exploit the overflow to execute arbitrary code on the affected embedded device.

CVSS 4.0 · 8.6 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-10442

Off-by-one error vulnerability in the transmission component in Synology Replication Service before 1.0.12-0066, 1.2.2-0353 and 1.3.0-0423 and Synology Unified Controller (DSMUC) before 3.1.4-23079 allows remote attackers to execute arbitrary code, potentially leading to a broader impact across the system via unspecified vectors.

CVSS 3.1 · 10 Critical EPSS 1.4% KEV · Not listed
CVE-2023-53397

modpost: fix off by one in is_executable_section()

In the Linux kernel, the following vulnerability has been resolved: modpost: fix off by one in is_executable_section() The > comparison should be >= to prevent an out of bounds array access.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-36957

octeontx2-af: avoid off-by-one read from userspace

In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: avoid off-by-one read from userspace We try to access count + 1 byte from userspace with memdup_user(buffer, count + 1). However, the userspace only provides buffer of count bytes and only these count bytes are verified to be okay to access. To ensure the copied buffer is NUL terminated, we use memdup_user_nul instead.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
CVE-2025-11215

chromium-browser: Off by one error in V8

Off by one error in V8 in Google Chrome prior to 141.0.7390.54 allowed a remote attacker to perform an out of bounds memory read via a crafted HTML page. (Chromium security severity: Medium)

CVSS 3.1 · 4.3 Medium EPSS < 1% KEV · Not listed
Vendors
Apple Google Linux and 1 more
Products
Macos Chrome V8 and 2 more
CVE-2023-53143

ext4: fix another off-by-one fsmap error on 1k block filesystems

In the Linux kernel, the following vulnerability has been resolved: ext4: fix another off-by-one fsmap error on 1k block filesystems Apparently syzbot figured out that issuing this FSMAP call: struct fsmap_head cmd = { .fmh_count = ...; .fmh_keys = { { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, { .fmr_device = /* ext4 dev */, .fmr_physical = 0, }, }, ... }; ret = ioctl(fd, FS_IOC_GETFSMAP, &cmd); Produces this crash if the underlying filesystem is a 1k-block ext4 filesystem: kernel BUG at fs/ext4/ext4.h:3331! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 3 PID: 3227965 Comm: xfs_io Tainted: G W O 6.2.0-rc8-achx Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:ext4_mb_load_buddy_gfp+0x47c/0x570 [ext4] RSP: 0018:ffffc90007c03998 EFLAGS: 00010246 RAX: ffff888004978000 RBX: ffffc90007c03a20 RCX: ffff888041618000 RDX: 0000000000000000 RSI: 00000000000005a4 RDI: ffffffffa0c99b11 RBP: ffff888012330000 R08: ffffffffa0c2b7d0 R09: 0000000000000400 R10: ffffc90007c03950 R11: 0000000000000000 R12: 0000000000000001 R13: 00000000ffffffff R14: 0000000000000c40 R15: ffff88802678c398 FS: 00007fdf2020c880(0000) GS:ffff88807e100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd318a5fe8 CR3: 000000007f80f001 CR4: 00000000001706e0 Call Trace: <TASK> ext4_mballoc_query_range+0x4b/0x210 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap_datadev+0x713/0x890 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_getfsmap+0x2b7/0x330 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] ext4_ioc_getfsmap+0x153/0x2b0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __ext4_ioctl+0x2a7/0x17e0 [ext4 dfa189daddffe8fecd3cdfd00564e0f265a8ab80] __x64_sys_ioctl+0x82/0xa0 do_syscall_64+0x2b/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fdf20558aff RSP: 002b:00007ffd318a9e30 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000000200c0 RCX: 00007fdf20558aff RDX: 00007fdf1feb2010 RSI: 00000000c0c0583b RDI: 0000000000000003 RBP: 00005625c0634be0 R08: 00005625c0634c40 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fdf1feb2010 R13: 00005625be70d994 R14: 0000000000000800 R15: 0000000000000000 For GETFSMAP calls, the caller selects a physical block device by writing its block number into fsmap_head.fmh_keys[01].fmr_device. To query mappings for a subrange of the device, the starting byte of the range is written to fsmap_head.fmh_keys[0].fmr_physical and the last byte of the range goes in fsmap_head.fmh_keys[1].fmr_physical. IOWs, to query what mappings overlap with bytes 3-14 of /dev/sda, you'd set the inputs as follows: fmh_keys[0] = { .fmr_device = major(8, 0), .fmr_physical = 3}, fmh_keys[1] = { .fmr_device = major(8, 0), .fmr_physical = 14}, Which would return you whatever is mapped in the 12 bytes starting at physical offset 3. The crash is due to insufficient range validation of keys[1] in ext4_getfsmap_datadev. On 1k-block filesystems, block 0 is not part of the filesystem, which means that s_first_data_block is nonzero. ext4_get_group_no_and_offset subtracts this quantity from the blocknr argument before cracking it into a group number and a block number within a group. IOWs, block group 0 spans blocks 1-8192 (1-based) instead of 0-8191 (0-based) like what happens with larger blocksizes. The net result of this encoding is that blocknr < s_first_data_block is not a valid input to this function. The end_fsb variable is set from the keys that are copied from userspace, which means that in the above example, its value is zero. That leads to an underflow here: blocknr = blocknr - le32_to_cpu(es->s_first_data_block); The division then operates on -1: offset = do_div(blocknr, EXT4_BLOCKS_PER_GROUP(sb)) >> EXT4_SB(sb)->s_cluster_bits; Leaving an impossibly large group number (2^32-1) in blocknr. ext4_getfsmap_check_keys checked that keys[0 ---truncated---

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2021-3156

sudo: Heap buffer overflow in argument parsing

Sudo before 1.9.5p2 contains an off-by-one error that can result in a heap-based buffer overflow, which allows privilege escalation to root via "sudoedit -s" and a command-line argument that ends with a single backslash character.

CVSS 3.1 · 7.8 High EPSS 100.0% KEV · Listed
Vendors
CVE-2023-44444

GIMP PSP File Parsing Off-By-One Remote Code Execution Vulnerability

GIMP PSP File Parsing Off-By-One Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GIMP. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of PSP files. Crafted data in a PSP file can trigger an off-by-one error when calculating a location to write within a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. . Was ZDI-CAN-22097.

CVSS 3.1 · 7.8 High EPSS 56.1% KEV · Not listed
Vendors
Products
CVE-2024-23849

kernel: off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access

In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-26995

usb: typec: tcpm: Correct the PDO counting in pd_set

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Correct the PDO counting in pd_set Off-by-one errors happen because nr_snk_pdo and nr_src_pdo are incorrectly added one. The index of the loop is equal to the number of PDOs to be updated when leaving the loop and it doesn't need to be added one. When doing the power negotiation, TCPM relies on the "nr_snk_pdo" as the size of the local sink PDO array to match the Source capabilities of the partner port. If the off-by-one overflow occurs, a wrong RDO might be sent and unexpected power transfer might happen such as over voltage or over current (than expected). "nr_src_pdo" is used to set the Rp level when the port is in Source role. It is also the array size of the local Source capabilities when filling up the buffer which will be sent as the Source PDOs (such as in Power Negotiation). If the off-by-one overflow occurs, a wrong Rp level might be set and wrong Source PDOs will be sent to the partner port. This could potentially cause over current or port resets.

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-47686

ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()

In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.

CVSS 3.1 · 7.1 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-38441

Netatalk before 3.2.1 has an off-by-one error and resultant heap-based buffer overflow because of setting ibuf[len] to '\0' in FPMapName in afp_mapname in etc/afpd/directory.c. 2.4.1 and 3.1.19 are also fixed versions.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-38440

Netatalk before 3.2.1 has an off-by-one error, and resultant heap-based buffer overflow and segmentation violation, because of incorrectly using FPLoginExt in BN_bin2bn in etc/uams/uams_dhx_pam.c. The original issue 1097 report stated: 'The latest version of Netatalk (v3.2.0) contains a security vulnerability. This vulnerability arises due to a lack of validation for the length field after parsing user-provided data, leading to an out-of-bounds heap write of one byte (\0). Under specific configurations, this can result in reading metadata of the next heap block, potentially causing a Denial of Service (DoS) under certain heap layouts or with ASAN enabled. ... The vulnerability is located in the FPLoginExt operation of Netatalk, in the BN_bin2bn function found in /etc/uams/uams_dhx_pam.c ... if (!(bn = BN_bin2bn((unsigned char *)ibuf, KEYSIZE, NULL))) ... threads ... [#0] Id 1, Name: "afpd", stopped 0x7ffff4304e58 in ?? (), reason: SIGSEGV ... [#0] 0x7ffff4304e58 mov BYTE PTR [r14+0x8], 0x0 ... mov rdx, QWORD PTR [rsp+0x18] ... afp_login_ext(obj=<optimized out>, ibuf=0x62d000010424 "", ibuflen=0xffffffffffff0015, rbuf=<optimized out>, rbuflen=<optimized out>) ... afp_over_dsi(obj=0x5555556154c0 <obj>).' 2.4.1 and 3.1.19 are also fixed versions.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2025-52497

Mbed TLS before 3.6.4 has a PEM parsing one-byte heap-based buffer underflow, in mbedtls_pem_read_buffer and two mbedtls_pk_parse functions, via untrusted PEM input.

CVSS 3.1 · 4.8 Medium EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2024-57259

sqfs_search_dir in Das U-Boot before 2025.01-rc1 exhibits an off-by-one error and resultant heap memory corruption for squashfs directory listing because the path separator is not considered in a size calculation.

CVSS 3.1 · 7.1 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2025-54349

iperf3: iperf Heap Buffer Overflow

In iperf before 3.19.1, iperf_auth.c has an off-by-one error and resultant heap-based buffer overflow.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
Es
Products
CVE-2025-53014

ImageMagick has Heap Buffer Overflow in InterpretImageFilename

ImageMagick is free and open-source software used for editing and manipulating digital images. Versions prior to 7.1.2-0 and 6.9.13-26 have a heap buffer overflow in the `InterpretImageFilename` function. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`). Versions 7.1.2-0 and 6.9.13-26 fix the issue.

CVSS 3.1 · 3.7 Low EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2025-21813

timers/migration: Fix off-by-one root mis-connection

In the Linux kernel, the following vulnerability has been resolved: timers/migration: Fix off-by-one root mis-connection Before attaching a new root to the old root, the children counter of the new root is checked to verify that only the upcoming CPU's top group have been connected to it. However since the recently added commit b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit") this check is not valid anymore because the old root is pre-accounted as a child to the new root. Therefore after connecting the upcoming CPU's top group to the new root, the children count to be expected must be 2 and not 1 anymore. This omission results in the old root to not be connected to the new root. Then eventually the system may run with more than one top level, which defeats the purpose of a single idle migrator. Also the old root is pre-accounted but not connected upon the new root creation. But it can be connected to the new root later on. Therefore the old root may be accounted twice to the new root. The propagation of such overcommit can end up creating a double final top-level root with a groupmask incorrectly initialized. Although harmless given that the final top level roots will never have a parent to walk up to, this oddity opportunistically reported the core issue: WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: <IRQ> ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt </IRQ> Fix the problem by taking the old root into account in the children count of the new root so the connection is not omitted. Also warn when more than one top level group exists to better detect similar issues in the future.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products