You need to log in before you can comment on or make changes to this bug.
In 3.9.4's tif_unix.c, I observe that _tiffSizeProc returns 0 on fstat() failure, while _tiffMapProc thinks that -1 is its failure code. So an fstat failure would result in mapping a zero-size chunk of the file and doubtless crashing soon thereafter. Now an fstat failure is sufficiently unlikely that this would seldom be an issue in practice, but I am suspicious that something of the sort happened here: https://bugzilla.redhat.com/show_bug.cgi?id=614745 I haven't done the legwork to see what other callers of the sizeproc think the failure result code is, so I'm not sure which function needs to change, but clearly one of them does. It might also be smart to inspect the other OS-specific modules for the same problem.
Actually, on closer analysis this doesn't explain that Red Hat bug: if the file were mapped zero length, it wouldn't have got as far as it did (see my comment #11 there). But it's still a bug, even if low probability.
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets, such as this one, have been migrated to the libtiff GitLab instance at https://gitlab.com/libtiff/libtiff/issues . The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is the initial Bugzilla issue number.
