You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
volk_get_config_path constructs file paths using strncpy/strcat pairs
that can overflow the destination buffer. volk_load_preferences reads
config lines with sscanf without field-width limits, allowing a crafted
config file to overflow stack buffers.
strncpy(path, home, 512) + strcat(path, suffix) — if home is >=495 chars, strcat writes past the buffer
volk_load_preferences line 98
sscanf(line, "%s %s %s", ...) — no width limit, writes into char[128] fields of volk_arch_pref_t
volk_load_preferences line 78
char path[512] passed to volk_get_config_path which uses a hardcoded 512-byte limit that doesn't match the caller
The sscanf vector is the more realistic concern: a crafted volk_config
file with a >127-character token causes a stack buffer overflow without
requiring unusual environment variables. Static analysis tools (Coverity,
CodeQL) flag sscanf without width limits as CWE-120 (buffer copy without
checking size of input).
Expected behavior
Path construction should use snprintf with explicit buffer size
sscanf should use width-limited format specifiers (%127s)
Caller and callee should agree on buffer size
Steps to reproduce
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="-fsanitize=address"
cmake --build build --target volk_profile -j$(nproc)# Trigger via long environment variable:export VOLK_CONFIGPATH=$(python3 -c "print('A'*600)")
build/apps/volk_profile --help
# ASan reports stack-buffer-overflow in volk_get_config_path
Environment
VOLK version:origin/main (commit ed15328) — has always been this way
Root cause
lib/volk_prefs.c uses strncpy + strcat for path construction (lines
35, 44, 53, 63). strncpy truncates to 512 bytes but does not guarantee
null-termination if the source fills the buffer. strcat then appends a
suffix (up to 18 chars) with no bounds check. The sscanf on line 98 reads
tokens of arbitrary length into 128-byte fields.
Related issues
Fork #12 fixes argument
parser crashes in volk_option_helpers.cc — same theme (input validation)
but different file.
PR volk_prefs: add XDG Base Directory support #11 (XDG Base Directory support) rewrites volk_get_config_path and
depends on this fix landing first to establish the safe snprintf pattern.
Summary
volk_get_config_pathconstructs file paths usingstrncpy/strcatpairsthat can overflow the destination buffer.
volk_load_preferencesreadsconfig lines with
sscanfwithout field-width limits, allowing a craftedconfig file to overflow stack buffers.
Current behavior
volk_get_config_path(3 user-controllable path blocks)strncpy(path, home, 512)+strcat(path, suffix)— ifhomeis >=495 chars,strcatwrites past the buffervolk_load_preferencesline 98sscanf(line, "%s %s %s", ...)— no width limit, writes intochar[128]fields ofvolk_arch_pref_tvolk_load_preferencesline 78char path[512]passed tovolk_get_config_pathwhich uses a hardcoded 512-byte limit that doesn't match the callerThe
sscanfvector is the more realistic concern: a craftedvolk_configfile with a >127-character token causes a stack buffer overflow without
requiring unusual environment variables. Static analysis tools (Coverity,
CodeQL) flag
sscanfwithout width limits as CWE-120 (buffer copy withoutchecking size of input).
Expected behavior
snprintfwith explicit buffer sizesscanfshould use width-limited format specifiers (%127s)Steps to reproduce
Environment
origin/main(commited15328) — has always been this wayRoot cause
lib/volk_prefs.cusesstrncpy+strcatfor path construction (lines35, 44, 53, 63).
strncpytruncates to 512 bytes but does not guaranteenull-termination if the source fills the buffer.
strcatthen appends asuffix (up to 18 chars) with no bounds check. The
sscanfon line 98 readstokens of arbitrary length into 128-byte fields.
Related issues
parser crashes in
volk_option_helpers.cc— same theme (input validation)but different file.
volk_get_config_pathanddepends on this fix landing first to establish the safe
snprintfpattern.