https://bugs.exim.org/show_bug.cgi?id=2274
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|tom@??? |pdp@???
Status|NEW |ASSIGNED
--- Comment #16 from Phil Pennock <pdp@???> ---
I can't speak to the unknown signal issue, but as regards the stack trace:
okay, I think I see a problem in the code.
I think that if there's a path to a config entry in your trusted configs file
[TRUSTED_CONFIG_LIST in Local/Makefile] which is longer than cwd+4, then we'll
hit this bug. The logic assumes that the memory store is zeroed out and that a
strncpy() will thus leave the copied string with NULs after it until the end of
the buffer.
There's nothing here which would have us write to bad memory; the problem is
going to be that immediately after the bad copy, we walk off it and keep
walking, looking for a place to write to. _If_ there's a NUL after the
big-buffer, before an unallocated memory region, then we might have issues, but
this early in the process lifecycle, that seems unlikely.
Alex, I think that you're triggering this because your log_selector includes
"arguments", either through "log_selector = +arguments" or "log_selector =
+all". As a work-around, you can remove arguments from the list of enabled log
features, and you'll no longer trigger this bug. Also, can you confirm that
there's a very long path-name in the file which your Local/Makefile's
TRUSTED_CONFIG_LIST points to?
--
You are receiving this mail because:
You are on the CC list for the bug.
