FreeBSD 12.2 - upstream project has reports of segvs from exim 4.95 and is debugging the issue. So far, we know we're getting fd values *well* over 1024, and since we use select() this is very likely to smash the stack. Possibly this will only occur on a reasonably-loaded server system, but any that is running long enough will be vulnerable. Presumably the change in behaviour is due to the FreeBSD kernel (no longer handing out the lowest usable fd, when creating a new handle?) and not actually due to the Exim version.
Moin! It's a known issue, see PR 258848 and ML discussion https://lists.exim.org/lurker/message/20211009.222513.c3ec4c7a.en.html Further updates will be in original update PR *** This bug has been marked as a duplicate of bug 258848 ***
Actually not; this issue is present even with the fix for 258848.
Note that Posix does say that the lowest possible fd should be returned by any open-like call: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_14 Since Exim didn't use to get crashes like this, I suspect a kernel behaviour change which has made FreeBSD nonconformant. A conversion to poll() is in progress - but if the above is true, other programs running a standard daemon-loop and using select are also at risk.
Upstream dd19ce4f24 addresses.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=99c5dc1049a23570016dcb5ac44882e408800622 commit 99c5dc1049a23570016dcb5ac44882e408800622 Author: Dima Panov <fluffy@FreeBSD.org> AuthorDate: 2021-12-28 19:23:16 +0000 Commit: Dima Panov <fluffy@FreeBSD.org> CommitDate: 2021-12-28 19:23:16 +0000 mail/exim: update to 4.95 release (+) Finally, Exim will be pushed to 4.95 release. Long wait was caused by some criticals errors in vanilla release, upstream fixes got a some time to come. * Apply sendfile patch, fixes SIGSEGV using clamd via TCP [1] * Convert select() to poll(), fixes crashes (SIGSEV) on FreeBSD 12.2 [2] PR: 258848 [1], 259822 [2] Sponsored by: Netzkommune GmbH mail/exim/Makefile | 35 +- mail/exim/distinfo | 6 +- ...fig-option-allow_insecure_tainted_.patch (gone) | 230 ----- mail/exim/files/debian/75_02-search.patch (gone) | 39 - mail/exim/files/debian/75_03-dbstuff.patch (gone) | 30 - mail/exim/files/debian/75_04-acl.patch (gone) | 67 -- mail/exim/files/debian/75_05-parse.patch (gone) | 30 - mail/exim/files/debian/75_06-rda.patch (gone) | 28 - .../files/debian/75_07-appendfile.patch (gone) | 34 - .../exim/files/debian/75_08-autoreply.patch (gone) | 70 -- mail/exim/files/debian/75_09-pipe.patch (gone) | 36 - mail/exim/files/debian/75_10-deliver.patch (gone) | 49 -- .../exim/files/debian/75_11-directory.patch (gone) | 26 - mail/exim/files/debian/75_12-expand.patch (gone) | 34 - .../files/debian/75_13-lf_sqlperform.patch (gone) | 49 -- .../debian/75_14-rf_get_transport.patch (gone) | 28 - mail/exim/files/debian/75_15-deliver.patch (gone) | 31 - mail/exim/files/debian/75_16-smtp_out.patch (gone) | 38 - mail/exim/files/debian/75_17-smtp.patch (gone) | 29 - .../files/debian/75_18-update-doc.patch (gone) | 154 ---- ...and-rejectlog_name-unconditionally.patch (gone) | 42 - .../files/debian/75_21-tidy-log.c.patch (gone) | 124 --- .../debian/75_22-Silence-compiler.patch (gone) | 222 ----- ...ain-_log-if-we-do-not-see-a-chance.patch (gone) | 166 ---- .../debian/75_24-Silence-the-compiler.patch (gone) | 57 -- ...s-for-mkdir-this-isn-t-part-of-4.9.patch (gone) | 27 - ...timeofday-select-per-char-for-cmdli.patch (new) | 616 ++++++++++++++ ...ll-uses-of-select-to-poll.-Bug-2831.patch (new) | 931 +++++++++++++++++++++ ...asic-memory-use-for-SPARC.-Bug-2838.patch (new) | 140 ++++ mail/exim/files/patch-OS_os.c-FreeBSD (new) | 15 + mail/exim/files/patch-OS_os.h-FreeBSD (gone) | 17 - mail/exim/files/patch-src__EDITME | 46 +- mail/exim/options | 1 - 33 files changed, 1736 insertions(+), 1711 deletions(-)
(In reply to j2465 from comment #3) Is there a reproducible test case (simple, not exim code, if possible) that exhibits a "bad fd" (not lowest possible) issued from an open(2)-like call? In other words, is there any verification of FreeBSD doing the wrong thing for new file descriptors?
Sorry, no. The observed case was a standard Unix daemon, TCP, accept()ing from a listen()ing bound socket. I doubt there was anything special about it, beyond being running at load as somebody's primary MTA. For verification: in core dumps we observed fd values in the 1030+ region.
(In reply to j2465 from comment #7) Here is a simple possibility... Run 'ktrace -id' on exim. The kdump would show the fd allocations. If you still have a way to reproduce this easily, run ktrace on it, and attach it here. It will be interesting to see if this really is a base FreeBSD problem, or it is perhaps triggered by something exim is doing.