It is possible to crash ucs2any or provoke successful return value even though the processing was not successful.
The problem lies within a possible integer overflow when adding elements with a key which is too large. You can trigger the issue this way on a 32 bit system: $ cat > source.bdf << "EOF" STARTFONT source CHARS 1 ENCODING 1073741823 EOF $ ucs2any source.bdf Segmentation fault $ _ Another possibility would be to add "ENCODING 1" right after the CHARS line. In that case, realloc will allocate 0 bytes afterwards which is a success but might return NULL, e.g. on Linux/glibc systems. Such a result value is handled as an error and errno is evaluated and returned, even though there was no error: $ cat > source.bdf << "EOF" STARTFONT source CHARS 1 ENCODING 1 ENCODING 1073741823 EOF $ ucs2any source.bdf ucs2any: Success $ echo $? 0 $ _ Signed-off-by: Tobias Stoeckmann <tob...@stoeckmann.org> --- ucs2any.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ucs2any.c b/ucs2any.c index 10bb029..1f575d1 100644 --- a/ucs2any.c +++ b/ucs2any.c @@ -45,6 +45,7 @@ #endif #include <limits.h> #include <stdarg.h> +#include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -220,6 +221,11 @@ da_add(da_t *da, int key, void *value) { int i = da->size; if (key >= 0) { + if ((size_t)key >= SIZE_MAX / sizeof(void *)) { + fprintf(stderr, "%s: Illegal key '%d' encountered!\n", + my_name, key); + exit(1); + } if (key >= da->size) { da->size = key + 1; da->values = zrealloc(da->values, -- 2.15.0 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel