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 -- [email protected]
To unsubscribe send an email to [email protected]
