[exim-dev] [Bug 1671] segfault after delivery

Startseite
Nachricht löschen
Nachricht beantworten
Autor: admin
Datum:  
To: exim-dev
Betreff: [exim-dev] [Bug 1671] segfault after delivery
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.