Security vulnerabilities and automated fixes for strcpy issues
13 posts found
A critical buffer overflow vulnerability was discovered in `buildroot-external/package/libxmlparser/xmlParser.cpp`, where the `toXMLString` function used `_tcscpy()` to write XML escape sequences into a destination buffer without any bounds checking. An attacker supplying a crafted XML document could overflow the buffer and potentially execute arbitrary code. The fix replaces all five unsafe `_tcscpy()` calls with `memcpy()` calls that copy only the exact number of bytes required for each escape
A high-severity buffer overflow risk was discovered in `login/main.c` where `strcpy()` was used to copy the `HOME` environment variable into a fixed-size 512-byte buffer without any bounds checking. An attacker controlling the `HOME` environment variable could overflow `pwd_file_name`, potentially corrupting memory or hijacking execution. The fix replaces the two-step `strcpy`/`strcat` pattern with a single, bounds-safe `snprintf` call.
A critical buffer overflow vulnerability was discovered in `intl/localename.c` where the `gl_locale_name_canonicalize()` function used unsafe `strcpy()` operations to copy locale names into fixed-size buffers without bounds checking. An attacker controlling locale environment variables could overflow the destination buffer, leading to memory corruption and potential code execution. The fix replaced `strcpy()` with bounded `strncpy()` calls to prevent buffer overruns.
A critical heap buffer overflow vulnerability was discovered in the `dupstr()` function inside `tools/strliteral.c`, where `strcpy()` was called on a heap-allocated buffer without first verifying that `malloc()` had succeeded. If `malloc()` returned `NULL`, the subsequent `strcpy()` would write into address zero — corrupting memory and potentially enabling arbitrary code execution. The fix replaces the unsafe `strcpy()` call with a `NULL` check followed by a bounds-safe `memcpy()`, closing the v
A critical buffer overflow vulnerability was discovered in `src/st-util/gdb-server.c` where unbounded `memcpy()` and `strcpy()` calls could write beyond allocated buffer boundaries when processing user-supplied command-line arguments. The fix replaces all unsafe string operations with bounds-checked alternatives like `snprintf()` and `memcpy()` with explicit length validation.
A high-severity buffer overflow vulnerability was discovered and fixed in `ubus.c` at line 577, where `strcpy()` was used to copy user-provided strings into dynamically allocated buffers without explicit size bounds checking. While current allocation logic correctly sizes the buffer, the use of `strcpy()` creates a dangerous coding pattern that could lead to exploitable memory corruption if the allocation logic ever changes or a TOCTOU race condition is introduced. The fix replaces the unbounded
A critical stack-based buffer overflow was discovered in `src/debugger.cpp` at line 387, where `strcpy` copied user-entered debugger commands into a fixed-size stack buffer (`prevCommandBuffer`) without any length validation. An attacker could craft an oversized command string to overflow the buffer, overwrite the return address, and achieve arbitrary code execution. The fix replaces `strcpy` with bounded `strncpy` and explicit null-termination.
A critical buffer overflow vulnerability was discovered in the 51Degrees NGINX module (`ngx_http_51D_module.c`), where four uses of unbounded `strcpy()` allowed attackers to overflow fixed-size heap buffers by sending HTTP requests with oversized header names. The fix replaces all unsafe string operations with length-bounded NGINX-native alternatives (`ngx_memcpy` and `ngx_cpystrn`), preventing memory corruption without any change to functional behavior.
A critical buffer overflow vulnerability was discovered in `lightcrafts/coprocesses/dcraw/dcraw_lz.c` at line 1334, where the `nikon_3700()` function used `strcpy()` to copy camera make and model strings into fixed 64-byte buffers without any bounds checking. A crafted RAW image file with oversized make/model metadata could trigger a heap or stack corruption, potentially enabling arbitrary code execution. The fix replaces both `strcpy()` calls with `strncpy()` and explicit null-termination, enfo
A critical buffer overflow vulnerability was discovered in `spdm_emu/spdm_emu_common/spdm_emu.c` at line 638, where an unbounded `strcpy()` call copied a user-supplied command-line argument directly into the fixed-size buffer `m_ip_address_string` without any length validation. An attacker able to invoke the `spdm_emu` binary with an oversized argument could corrupt adjacent memory and potentially achieve arbitrary code execution. The fix replaces the unsafe `strcpy()` with a bounded `strncpy()`
A critical buffer overflow vulnerability was discovered in `gravier/gravier-str.h`, where a subtle typo in the `next_power_of_2()` function combined with off-by-one allocation errors and unchecked `strcpy()` calls created a dangerous memory corruption pathway. Because this code was directly reachable from user-facing menu text input and the s7 scripting engine, an attacker could potentially exploit it to crash the application or execute arbitrary code. The fix corrects the broken bit-shift opera
A critical buffer overflow vulnerability was discovered and patched in `src/utils/utils.c`, where five unguarded calls to `strcpy()` allowed attacker-controlled strings from external configuration files to overwrite stack and heap memory. This class of vulnerability — one of the oldest and most dangerous in systems programming — can lead to arbitrary code execution, privilege escalation, or full application compromise. The fix replaces unsafe string operations with bounds-checked alternatives, c