Turns out that it is undefined behaviour to pass a value to isctype functions
which does not fit inside a char. Closes #312

(cf #309)

Closes #303

closes #302

closes #270

Check malloc return value for NULL.

Fixed memory leak on file name collision.

Always terminate strncpy results with '\0'.

Avoid out of boundary read on empty/broken file.

If malloc cannot allocate enough memory, it could return NULL. This is
not necessarily true for default Linux settings, but can be provoked
there as well by adjusting proc entries. Other systems like the *BSD
ones definitely do this.

The function _emalloc exists for exactly this purpose, so use it instead
of calling malloc directly.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

If feh_unique_filename encounters a file that already exists, the memory
for the temporary filename is not released. As this happens in /tmp at
some code places, an attacker could use this to spray the memory of feh,
or simply triggering an out of memory condition.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

If ereadfile encounters an empty file or the file could not be read, an
out ouf boundary read (and possible write) occurs. Always check the
return value of fread to be > 0 before processing the result buffer.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

The strncpy function does not guarantee to end the resulting character
sequence with a terminating nul character if not enough space is
available. This could be triggered by supplying a sufficiently long
output_file option.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>

Fix double-free/OOB-write while receiving IPC data

If a malicious client pretends to be the E17 window manager, it is
possible to trigger an out of boundary heap write while receiving an
IPC message.

The length of the already received message is stored in an unsigned
short, which overflows after receiving 64 KB of data. It's comparably
small amount of data and therefore achievable for an attacker.

When len overflows, realloc() will either be called with a small value
and therefore chars will be appended out of bounds, or len + 1 will be
exactly 0, in which case realloc() behaves like free(). This could be
abused for a later double-free attack as it's even possible to overwrite
the free information -- but this depends on the malloc implementation.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>