John Fawcett via Postfix-users: > > On 08/08/2024 22:36, Wietse Venema via Postfix-users wrote: > > Paul Menzel via Postfix-users: > >>> Stack trace of thread 468215: > >>> #0 0x0000000000404610 strlcpy (vacation + 0x4610) > >>> #1 0x0000000000402e0e main (vacation + 0x2e0e) > >>> #2 0x00007f2a6f8a0088 __libc_start_call_main > >>> (libc.so.6 + 0x2a088) > >>> #3 0x00007f2a6f8a014b __libc_start_main@@GLIBC_2.34 > >>> (libc.so.6 + 0x2a14b) > >>> #4 0x0000000000403525 _start (vacation + 0x3525) > >>> ELF object binary architecture: AMD x86-64 > > The root cause could be an unexpected message header. > > > > There are only four strlcpy() calls in the source package for Fedora. > > One is to copy the username as looked up from the passwd database, > > and the other calls copy information from the From_ line (the first > > line of the vacation input) or from the From: header. > > > > The strlcpy() manpage says: > > > > strlcpy(3bsd) and strlcat(3bsd) are designed to crash if the input > > string is invalid (doesn't contain a terminating null byte). > > > > Do the failing deliveries have the same sender? > > > > Wietse > > If the stack trace is to be believed the coredump happens in strlcpy > called from main. There is only one strlcpy that is called from main and > that is the one that copies the username as looked up from the passwd > database. That only happens when there is a -h option on the command > line, which doesn't seem to be the case. That seems to suggest that > neither a code error or message input is the cause. > > Despite the freebsd manual page the strlcpy code in vacation looks safe > to me even when copying strings that are not terminated by null.
It's a fedora40 system. But yes, vacation has changed and there is only one strlcpy() call in main. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org