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
{{ message }}
Repository navigation
[BUG] Undefined behavior in ctype functions when processing non-ASCII characters in ffCharIsSpace and strutil #2721
In src/util/FFstrutil.h and related string utility functions (e.g. ffCharIsSpace), characters of type char are passed directly to <ctype.h> functions such as isspace(), isblank(), and isalnum() without being cast to unsigned char.
According to the ISO C standard (C99 §7.4 paragraph 1, C11 §7.4 paragraph 1) and POSIX.1-2008:
In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined.
On architectures where char is signed (default on x86_64 Linux, macOS, and Windows), any non-ASCII character (e.g. byte values with the high bit set 0x80 to 0xFF, common in UTF-8 multibyte sequences for international text, hostnames, usernames, or distro names) is converted to a negative int due to sign extension.
When passed to standard library implementations such as GNU libc (glibc), musl, or MSVC, the negative index accesses memory before the *__ctype_b_loc() lookup table:
In debug builds or with ASan/UBSan (-fsanitize=undefined), this triggers an undefined behavior diagnostic or crash.
In production, it reads out-of-bounds memory from the ctype lookup array, potentially causing misclassification, crashes (SIGSEGV), or memory safety violations.
Version used
Fastfetch 2.38.0 (commit from dev branch)
Bug prevalence
Always (whenever non-ASCII UTF-8 characters or bytes with high-bit set are evaluated)
Regression
No
Installation
Built from source
Expected behavior
Characters passed to <ctype.h> functions should be safely cast to (unsigned char) before promotion to int:
Activity