https://bugs.exim.org/show_bug.cgi?id=1671
--- Comment #5 from Wolfgang Breyha <wbreyha@???> ---
Created attachment 828
-->
https://bugs.exim.org/attachment.cgi?id=828&action=edit
fix SIGSEGV for split_directory
I think, I found *one* reason.... first of all it only happens if
split_spool_directory = true
is used.
The patch Phil referred to contains the following for transport.c near
exim-4.86/src/transport.c:1755
--------
if (split_spool_directory)
- sprintf(CS(buffer + path_len), "%c/%s-D", new_message_id[5],
new_message_id);
+ sprintf(CS spool_file, "%s%c/%s-D",
+ spool_dir, new_message_id[5], msgq[i].message_id);
else
- sprintf(CS(buffer + path_len), "%s-D", new_message_id);
+ sprintf(CS spool_file, "%s%s-D", spool_dir, msgq[i].message_id);
--------
In case of split_spool_directory the usage of new_messsage_id[5] is a leftover
IMO. On the first run it is an undefined buffer, allocated by
transports/smtp.c:smtp_deliver() using
uschar new_message_id[MESSAGE_ID_LENGTH + 1];
and "most likely" containing 0 bytes on first run. Used in sprintf it cuts
spool_file short to the contents of spool_dir which also means that the
following Ustat(spool_file, ...) always succeeds.
Using msgq[i].message_id[5] should be correct. See attachment.
That fixes the obvious... but IMO there is room for a race. Since the Ustat
does not use locking it is still possible that it succeeds on a message which
is currently delivered by an other process. So I think further changes are
necessary to check for missing spool files and return values in
smtp_are_same_identities() not only for split_directory setups.
--
You are receiving this mail because:
You are on the CC list for the bug.
