| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Check malloc return value for NULL.
|
|
Fixed memory leak on file name collision.
|
|
Always terminate strncpy results with '\0'.
|
|
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>
|
|
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>
|
|
|
|
|
|
|
|
like %o and %z in slideshow actions (I would like to use this to zoom in, pan,
and then use an action to crop the window to zoomed in view).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixed(?) Makefile document build issue for README.md
|
|
|
|
|
|
On some systsems sysconf() can return a very large value, unsuitable for
use with malloc(). Only use sysconf() if HOST_NAME_MAX isn't avalable.
|
|
FreeBSD lacks the constant HOST_NAME_MAX, instead using sysconf(3) to
find out the value of the maximum host name length at run time. Patch
to use this instead of HOST_NAME_MAX.
This brings with it the need to use malloc instead of using a statically
sized buffer for the host name, since the size of the buffer cannot be
known at run time. Errors from sysconf or malloc just means that the
entire block of code is skipped over (the same way it's skipped if the
call to gethostname() fails), rather than returning any kind of error to
the caller or logging an error message somewhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is kinda sloppy coding (feh --filelist and --bg-* will fail when running
on a system with path lengths >= 4096 and PATH_MAX not defined), but that's
sufficiently improbable to be okay. (plus, I ain't getting paid for this, so
if you want to improve it feel free to do so)
|
|
Many image collections are organized by directory, so it is nice to have
jump-to-adjacent-directory navigation.
e.g. Given the following file hierarchy:
.
├── A
│ ├── 1.jpg
│ ├── 2.jpg
│ └── C
│ ├── 1.jpg
│ ├── 2.jpg
│ └── 3.jpg
└── B
├── 1.jpg
├── 2.jpg
└── 3.jpg
`feh --recursive` creates the following filelist:
A/1.jpg <---- current_file
A/2.jpg
A/C/1.jpg
A/C/2.jpg
A/C/3.jpg
B/1.jpg
B/2.jpg
B/3.jpg
If we press [next_dir], we move the current_file pointer to:
A/1.jpg
A/2.jpg
A/C/1.jpg <-- current_file
A/C/2.jpg
A/C/3.jpg
B/1.jpg
B/2.jpg
B/3.jpg
Pressing [next_dir] again moves the pointer to:
A/1.jpg
A/2.jpg
A/C/1.jpg
A/C/2.jpg
A/C/3.jpg
B/1.jpg <---- current_file
B/2.jpg
B/3.jpg
[next_dir] now moves the pointer back to the top of the list:
A/1.jpg <---- current_file
A/2.jpg
A/C/1.jpg
A/C/2.jpg
A/C/3.jpg
B/1.jpg
B/2.jpg
B/3.jpg
Pressing [prev_dir] from here moves backwards to the first image of the
previous directory:
A/1.jpg
A/2.jpg
A/C/1.jpg
A/C/2.jpg
A/C/3.jpg
B/1.jpg <---- current_file
B/2.jpg
B/3.jpg
When starting from an position that is not the first image of a
directory, [prev_dir] moves the pointer to the first image of the
current directory.
These actions combine well with `--sort dirname` since all regular files
in a directory will be sorted before any subdirectories, avoiding a
filelist like the following:
A/1.jpg
A/SUBDIR/2.jpg
A/SUBDIR/3.jpg
A/4.jpg
With `--sort dirname` that filelist becomes:
A/1.jpg
A/4.jpg
A/SUBDIR/2.jpg
A/SUBDIR/3.jpg
|
|
Sort filelist by dirname, then by name. This results in file entries
sorting before subdirectory entries.
Useful in conjunction with upcoming prev_dir and next_dir navigation
actions.
|
