Exim rejects mail due to a error while using Regex with: bad internal_store_malloc request from function_store_get 66 Downgrade to Exim 4.96 not possible due to missing ebuild. Reproducible: Always Steps to Reproduce: 1. When email with a size of 3.8M or bigger arrives 2. The exim.conf uses RegEx 3. Exim Version is 4.7 or bigger.
Does this look like https://bugs.exim.org/show_bug.cgi?id=3047 to you? 4.96 was removed for security reasons, but I can bring it back and mask it, or you fetch it yourself and put it in an overlay. https://gitweb.gentoo.org/repo/gentoo.git/plain/mail-mta/exim/exim-4.96.2-r1.ebuild?id=63565ffa98c1f5c69d3f38002934041f54411fca
if it is, wrt https://bugs.exim.org/show_bug.cgi?id=3047#c24, please do try unkw'd libpcre2-10.43_rc1
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7125e469ee81e0899df0a174d72fe90b774cb356 commit 7125e469ee81e0899df0a174d72fe90b774cb356 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-01-26 19:06:36 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-01-26 19:06:36 +0000 mail-mta/exim-4.97.1-r1: bump for upstream candidate patch plugging memuse PCRE2 changed the amount of memory it allocates considerably, making it necessary to cleanup more often. Bug: https://bugs.gentoo.org/922780 Signed-off-by: Fabian Groffen <grobian@gentoo.org> mail-mta/exim/exim-4.97.1-r1.ebuild | 631 +++++++++++++++++++++ .../files/exim-4.97.1-memory-usage-bug-3047.patch | 56 ++ 2 files changed, 687 insertions(+)
Would appreciate if you could try 4.97.1-r1 and report if that helps sufficiently for your setup. Thanks!
--- Comment #40 from Jeremy Harris <jgh146exb@wizmail.org> --- On investigation, it wouldn't help (which I should have realised). The allocate uses Exim's memory management which does not support individual alloc block free; only a mass release of a stack of allocations. The issue should be addressed by commits b4e7527561f1 and 35aacb69f5c8. -------- https://bugs.exim.org/show_bug.cgi?id=3047#c40 more patching is required
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=662e4585eef68252845c897c989764dddd350141 commit 662e4585eef68252845c897c989764dddd350141 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-01-28 18:18:46 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-01-28 18:20:00 +0000 mail-mta/exim-4.97.1-r2: update upstream patches for pcre2 memory usage Bug: https://bugs.gentoo.org/922780 Signed-off-by: Fabian Groffen <grobian@gentoo.org> ...exim-4.97.1-r1.ebuild => exim-4.97.1-r2.ebuild} | 0 .../files/exim-4.97.1-memory-usage-bug-3047.patch | 210 +++++++++++++++++++-- 2 files changed, 190 insertions(+), 20 deletions(-)
I noticed than since =mail-mta/exim-4.97.1-r2 I have a lot of left files in spool directory, mails are NOT delivered. Also there is no log line about in in exim_main.log . I don't know yet why some mails are delivered and other doesn't. Also I didn't do any debug yet but I would like to warn that something can be wrong with this patch.
Thanks, made a note on the upstream bug about your findings.
(In reply to Marcin Mirosław from comment #7) > Also I didn't do any debug yet A run with the daemon started with "-d +all", and a single message fed in, if this is SMTP traffic; or a commandline/stdin with that option if it is local-source traffic.
Hi Jeremy! First information, I use "split_spool_directory = true". And I can trigger bug on demand (sending email fom external service to my mx), I'll paste a small snippet from debug log, I think this is most important part of it. If more log will be needed please let mo know. [...] 14:26:55 32586 ├───item-res: X-Envelope-To: xxx@yyy.zz 14:26:55 32586 14:26:55 32586 ╰──(tainted) 14:26:55 32586 ├──expanding: From ${if def:return_path{$return_path}{MAILER-DAEMON}} ${tod_bsdinbox} 14:26:55 32586 ${if def:sender_address{X-Envelope-From: <${sender_address}> 14:26:55 32586 }}${if def:recipients{X-Envelope-To: ${recipients} 14:26:55 32586 }} 14:26:55 32586 ╰─────result: From zzzz@aaaa Wed Feb 07 14:26:55 2024 14:26:55 32586 X-Envelope-From: <zzzz@aaaa> 14:26:55 32586 X-Envelope-To: xxx@yyy.zz 14:26:55 32586 14:26:55 32586 ╰──(tainted) 14:26:55 32586 compiled RE '^(?i)Content-Disposition:(.*?)filename=\s*"+(({[a-hA-H0-9-]{25,}})|((.*?)\s{10,}(.*?)))"+$' found in local cache corrupted double-linked list (not small) 14:26:55 29900 child 32586 ended: status=0x6 14:26:55 29900 signal exit, signal 6 14:26:55 29900 0 SMTP accept processes now running 14:26:55 29900 Listening... 14:27:03 29900 SIGALRM received 14:27:03 29900 daemon forking for queue-runner 14:27:03 29900 daemon forked for queue-runner: 32604 14:27:03 29900 1 queue-runner process running 14:27:03 29900 Listening... 14:27:03 32604 postfork: queue-runner [...] Probably it's time to run it under gdb?
(also... why nothing is wrote to log file?)
(In reply to Marcin Mirosław from comment #10) > small snippet from debug log, I think this is most important part of it. That give something to chase, but... > 14:26:55 32586 compiled RE > '^(?i)Content-Disposition:(.*?)filename=\s*"+(({[a-hA-H0-9-]{25,}})|((. > *?)\s{10,}(.*?)))"+$' found in local cache > corrupted double-linked list (not small) > 14:26:55 29900 child 32586 ended: status=0x6 ... the string "double-linked" is nowhere in the Exim source. I expect it's in libpcre2 - but it could be down to how Exim is using it. > > Probably it's time to run it under gdb? It'd be useful background, but before that - can I guess from the RE that this is being done in a data-ish ACL? (we'd not accepted the message yet, so no <= log line. Presumably no custom ACL-driven logging.)
In acl_data: deny message = Hiding of file extensions is not allowed! /\ Ukrywanie(CLSID) rozszerzenia zalacznika jest niedozwolone! log_message = Dangerous extension (CLSID hidden) regex = ^(?i)Content-Disposition::(.*?)filename=\\s*"+((\{[a-hA-H0-9-]{25,}\})|((.*?)\\s{10,}(.*?)))"+\$
I something I should do now or should I wait, Jeremy?
> corrupted double-linked list (not small) That string is from glibc's allocator when it detects corruption. Can you try Valgrind or ASAN?
(In reply to Larry the Git Cow from comment #6) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=662e4585eef68252845c897c989764dddd350141 > > commit 662e4585eef68252845c897c989764dddd350141 > Author: Fabian Groffen <grobian@gentoo.org> > AuthorDate: 2024-01-28 18:18:46 +0000 > Commit: Fabian Groffen <grobian@gentoo.org> > CommitDate: 2024-01-28 18:20:00 +0000 > > mail-mta/exim-4.97.1-r2: update upstream patches for pcre2 memory usage > > Bug: https://bugs.gentoo.org/922780 > Signed-off-by: Fabian Groffen <grobian@gentoo.org> > > ...exim-4.97.1-r1.ebuild => exim-4.97.1-r2.ebuild} | 0 > .../files/exim-4.97.1-memory-usage-bug-3047.patch | 210 > +++++++++++++++++++-- > 2 files changed, 190 insertions(+), 20 deletions(-) That commit seems to pick up the appendfile transport fix but not the ACL regex fix. b4e7527561f1 and 35aacb69f5c8 in the exim git, respectively. Please check you have the regex fix.
I picked these two and squashed them into a single patch: From b4e7527561f1c68b821d5cf25efe29ae63d1d434 Mon Sep 17 00:00:00 2001 From: Jeremy Harris <jgh146exb@wizmail.org> Date: Thu, 25 Jan 2024 17:48:43 +0000 Subject: [PATCH] Appendfile: release regex-match store every thousand files. Bug 3047 From 35aacb69f5c839a4b77158464e401d86eb422ed6 Mon Sep 17 00:00:00 2001 From: Jeremy Harris <jgh146exb@wizmail.org> Date: Fri, 26 Jan 2024 21:58:59 +0000 Subject: [PATCH] ACL: in "regex" condition, release store every thousand lines. Bug 3047 Just re-checked, seems we have the content modulo some of the cosmetic changes which I left out to make the patch smaller.
OK. Next step is gdb, to check if the crash is in the glibc memory management called from exim itself, or called by the pcre2 library. If it's the latter then that upstream needs to get involved.
How to run gdb to catch forked process?
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Forks.html#index-debugging-multiple-processes
Probably I did gdb debugging with success but I can't interpret it, no C skills. (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f3f73db9f43 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f3f73d691a6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f3f73d518b7 in __GI_abort () at abort.c:79 #4 0x00007f3f73d52717 in __libc_message (fmt=fmt@entry=0x7f3f73ecb578 "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x00007f3f73dc4127 in malloc_printerr (str=str@entry=0x7f3f73ece180 "corrupted double-linked list (not small)") at malloc.c:5765 #6 0x00007f3f73dc4aa2 in unlink_chunk (p=p@entry=0x5640f734d480, av=0x7f3f73f05ac0 <main_arena>) at malloc.c:1624 #7 0x00007f3f73dc6084 in _int_free_merge_chunk (av=0x7f3f73f05ac0 <main_arena>, p=0x5640f734d480, size=36912) at malloc.c:4689 #8 0x00007f3f73dc62c5 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>, have_lock@entry=0) at malloc.c:4639 #9 0x00007f3f73dc8c93 in __GI___libc_free (mem=<optimized out>) at malloc.c:3391 #10 0x00007f3f73db1609 in __GI__IO_setb (f=f@entry=0x5640f734d2b0, b=b@entry=0x0, eb=eb@entry=0x0, a=a@entry=0) at genops.c:331 #11 0x00007f3f73dae8ab in _IO_new_file_close_it (fp=fp@entry=0x5640f734d2b0) at fileops.c:153 #12 0x00007f3f73da23a3 in _IO_new_fclose (fp=fp@entry=0x5640f734d2b0) at iofclose.c:53 #13 0x00005640f6763045 in regex (listptr=listptr@entry=0x7ffd3cba8dc0, cacheable=<optimized out>) at regex.c:170 #14 0x00005640f66c925f in acl_check_condition (verb=2, cb=0x5640f726ea20, where=where@entry=5, addr=addr@entry=0x0, level=<optimized out>, epp=epp@entry=0x7ffd3cba8e6c, user_msgptr=0x7ffd3cba92b0, log_msgptr=0x7ffd3cba92b8, basic_errno=0x7ffd3cba8e68) at acl.c:3947 #15 0x00005640f66c9d50 in acl_check_internal (where=where@entry=5, addr=addr@entry=0x0, s=s@entry=0x5640f726bce8 "acl_check_data", user_msgptr=user_msgptr@entry=0x7ffd3cba92b0, log_msgptr=log_msgptr@entry=0x7ffd3cba92b8) at acl.c:4428 #16 0x00005640f66ca76e in acl_check (where=where@entry=5, recipient=recipient@entry=0x0, s=0x5640f726bce8 "acl_check_data", user_msgptr=user_msgptr@entry=0x7ffd3cba92b0, log_msgptr=log_msgptr@entry=0x7ffd3cba92b8) at acl.c:4742 #17 0x00005640f6726267 in receive_msg (extract_recip=extract_recip@entry=0) at receive.c:3689 #18 0x00005640f66ce514 in handle_smtp_call (fd_polls=fd_polls@entry=0x5640f725f670, listen_socket_count=listen_socket_count@entry=6, accept_socket=accept_socket@entry=10, accepted=accepted@entry=0x7ffd3cba96c0) at daemon.c:560 #19 0x00005640f66d0b61 in daemon_go () at daemon.c:2809 #20 0x00005640f66eb0de in main (argc=4, cargv=0x7ffd3cbe9c38) at exim.c:5138 (gdb) bt full #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 tid = <optimized out> ret = 0 pd = <optimized out> old_mask = {__val = {34}} ret = <optimized out> #1 0x00007f3f73db9f43 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 No locals. #2 0x00007f3f73d691a6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #3 0x00007f3f73d518b7 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {94837025309664, 4294967295, 94837012400519, 0, 0, 0, 94837025330344, 0, 94837025330388, 94837025330388, 0, 4294967297, 94837025330343, 6442450944, 0, 0}}, sa_flags = 0, sa_restorer = 0x0} #4 0x00007f3f73d52717 in __libc_message (fmt=fmt@entry=0x7f3f73ecb578 "%s\n") at ../sysdeps/posix/libc_fatal.c:150 ap = {{gp_offset = 16, fp_offset = 0, overflow_arg_area = 0x7ffd3cba8c00, reg_save_area = 0x7ffd3cba8b90}} fd = 2 list = <optimized out> nlist = <optimized out> cp = <optimized out> #5 0x00007f3f73dc4127 in malloc_printerr (str=str@entry=0x7f3f73ece180 "corrupted double-linked list (not small)") at malloc.c:5765 No locals. #6 0x00007f3f73dc4aa2 in unlink_chunk (p=p@entry=0x5640f734d480, av=0x7f3f73f05ac0 <main_arena>) at malloc.c:1624 fd = <optimized out> bk = <optimized out> #7 0x00007f3f73dc6084 in _int_free_merge_chunk (av=0x7f3f73f05ac0 <main_arena>, p=0x5640f734d480, size=36912) at malloc.c:4689 prevsize = <optimized out> nextchunk = 0x5640f73564b0 nextsize = 33426256 #8 0x00007f3f73dc62c5 in _int_free (av=<optimized out>, p=<optimized out>, have_lock=<optimized out>, have_lock@entry=0) at malloc.c:4639 size = <optimized out> fb = <optimized out> #9 0x00007f3f73dc8c93 in __GI___libc_free (mem=<optimized out>) at malloc.c:3391 ar_ptr = <optimized out> p = <optimized out> err = 2 #10 0x00007f3f73db1609 in __GI__IO_setb (f=f@entry=0x5640f734d2b0, b=b@entry=0x0, eb=eb@entry=0x0, a=a@entry=0) at genops.c:331 No locals. #11 0x00007f3f73dae8ab in _IO_new_file_close_it (fp=fp@entry=0x5640f734d2b0) at fileops.c:153 write_status = 0 close_status = 0 #12 0x00007f3f73da23a3 in _IO_new_fclose (fp=fp@entry=0x5640f734d2b0) at iofclose.c:53 _IO_acquire_lock_file = 0x5640f734d2b0 status = <optimized out> #13 0x00005640f6763045 in regex (listptr=listptr@entry=0x7ffd3cba8dc0, cacheable=<optimized out>) at regex.c:170 mbox_size = 154973 mbox_file = 0x5640f734d2b0 re_list_head = 0x7f3f73b512e0 linebuffer = <optimized out> f_pos = 0 ret = 2 cnt = 1 lcount = <optimized out> reset_point = 0x7f3f73b511b0 __FUNCTION__ = "regex" #14 0x00005640f66c925f in acl_check_condition (verb=2, cb=0x5640f726ea20, where=where@entry=5, addr=addr@entry=0x0, level=<optimized out>, epp=epp@entry=0x7ffd3cba8e6c, user_msgptr=0x7ffd3cba92b0, log_msgptr=0x7ffd3cba92b8, basic_errno=0x7ffd3cba8e68) at acl.c:3947 arg = 0x7f3f73b510f0 "^(?i)Content-Disposition::(.*?)filename=\\s*\"+(({[a-hA-H0-9-]{25,}})|((.*?)\\s{10,}(.*?)))\"+$" control_type = <optimized out> textonly = 1 user_message = 0x5640f726e948 "Hiding of file extensions is not allowed! /Ukrywanie(CLSID) rozszerzenia zalacznika jest niedozwolone!" log_message = 0x5640f726e9d0 "Dangerous extension (CLSID hidden)" rc = 0 __FUNCTION__ = "acl_check_condition" #15 0x00005640f66c9d50 in acl_check_internal (where=where@entry=5, addr=addr@entry=0x0, s=s@entry=0x5640f726bce8 "acl_check_data", user_msgptr=user_msgptr@entry=0x7ffd3cba92b0, log_msgptr=log_msgptr@entry=0x7ffd3cba92b8) at acl.c:4428 cond = <optimized out> basic_errno = 0 endpass_seen = 0 acl_quit_check = <optimized out> fd = <optimized out> acl = 0x5640f726e908 acl_name = 0x7f3f73b510a0 "ACL \"acl_check_data\"" ss = <optimized out> __FUNCTION__ = "acl_check_internal" #16 0x00005640f66ca76e in acl_check (where=where@entry=5, recipient=recipient@entry=0x0, s=0x5640f726bce8 "acl_check_data", user_msgptr=user_msgptr@entry=0x7ffd3cba92b0, log_msgptr=log_msgptr@entry=0x7ffd3cba92b8) at acl.c:4742 rc = <optimized out> adb = {next = 0x5640f679241d, parent = 0x94b473bc44a96e00, first = 0x3d, dupof = 0x5640f6745e7e <strncmpic+29>, start_router = 0x5640f72fe140, router = 0x0, transport = 0x55640f6792415, host_list = 0x1, host_used = 0x7f3f743aeb40 <sha256_md>, fallback_hosts = 0x5640f67a1640, reply = 0x7ffd3cba9030, retries = 0x5640f7335810, address = 0x5640f7335a66 "Message-ID", unique = 0x5640f678972a <dkim_sig_to_a_tag+96> "H\203\304\b\303H\215\005\265~\001", cc_local_part = 0x5640f72fdd88 "", lc_local_part = 0xf678c955 <error: Cannot access memory at address 0xf678c955>, local_part = 0x5640f72fdd30 "2", prefix = 0x0, prefix_v = 0x1f6805683 <error: Cannot access memory at address 0x1f6805683>, suffix = 0xf68069f8 <error: Cannot access memory at address 0xf68069f8>, suffix_v = 0x5640f6805683 <debug_buffer+419> "", domain = 0x0, address_retry_key = 0x5640f72fe0f8 "\026{/\v\341,d\345\364A[\217\226\240\302\233\342\333\316؞rlle\023|\026\026\265\323=\035", domain_retry_key = 0x20 <error: Cannot access memory at address 0x20>, current_dir = 0x4d430001 <error: Cannot access memory at address 0x4d430001>, home_dir = 0x5640f7336178 "\201", message = 0x98 <error: Cannot access memory at address 0x98>, user_message = 0x0, onetime_parent = 0x4d430001 <error: Cannot access memory at address 0x4d430001>, pipe_expandn = 0x5640f7309448, return_filename = 0x10 <error: Cannot access memory at address 0x10>, self_hostname = 0x0, shadow_message = 0x0, tlsver = 0x0,
(In reply to Marcin Mirosław from comment #21) > Probably I did gdb debugging with success but I can't interpret it, no C > #12 0x00007f3f73da23a3 in _IO_new_fclose (fp=fp@entry=0x5640f734d2b0) at > iofclose.c:53 > _IO_acquire_lock_file = 0x5640f734d2b0 > status = <optimized out> > #13 0x00005640f6763045 in regex (listptr=listptr@entry=0x7ffd3cba8dc0, > cacheable=<optimized out>) at regex.c:170 Oh, that's fun :) fclose() called directly from exim's regex() function; this is nothing to do with pcre. The stdio library shouldn't be using exim memory management, so this implies a wild pointer has corrupted the glibc mem-management data. I'll think further on that. There's a follow-on patch for Exim just pushed, 84add256b346, which addresses a deficiency in one of the previous pair. I don't think it could produce this effect, but I do recommend picking it up.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2582b32d9016fdda44afd8cbbfbb198584e14c41 commit 2582b32d9016fdda44afd8cbbfbb198584e14c41 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-02-11 20:05:31 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-02-11 20:05:31 +0000 mail-mta/exim-4.97.1-r3: update regex memory patch Include 84add256b346 from upstream. Bug: https://bugs.gentoo.org/922780 Signed-off-by: Fabian Groffen <grobian@gentoo.org> ...exim-4.97.1-r2.ebuild => exim-4.97.1-r3.ebuild} | 0 .../files/exim-4.97.1-memory-usage-bug-3047.patch | 35 +++++++++++++++++++++- 2 files changed, 34 insertions(+), 1 deletion(-)
rc3 - little change: 21:30:40 22535 daemon_notification (from unknown addr) 21:30:40 22535 compiled RE '^(?i)Content-Disposition:(.*?)filename=\s*"+(({[a-hA-H0-9-]{25,}})|((.*?)\s{10,}(.*?)))"+$' not found in local cache 21:30:40 22535 compiling RE '^(?i)Content-Disposition:(.*?)filename=\s*"+(({[a-hA-H0-9-]{25,}})|((.*?)\s{10,}(.*?)))"+$' 21:30:40 22535 compiled RE '^(?i)Content-Disposition:(.*?)filename=\s*"+(({[a-hA-H0-9-]{25,}})|((.*?)\s{10,}(.*?)))"+$' saved in local cache 21:30:40 22535 Listening... corrupted double-linked list (not small) 21:30:40 22535 child 22563 ended: status=0x6 21:30:40 22535 signal exit, signal 6 21:30:40 22535 0 SMTP accept processes now running 21:30:40 22535 Listening... ^C21:30:43 22535 SIGTERM/SIGINT seen
(In reply to Marcin Mirosław from comment #24) Valgrind may well help with identifying the first point of corruption, as by the time glibc's allocator aborts, it's quite late.
I don't know how to use valgrind... But I tried, is it good catch from log? ==16352== Invalid write of size 8 ==16352== at 0x484D533: memmove (vg_replace_strmem.c:1400) ==16352== by 0x5222E31: memcpy (string_fortified.h:29) ==16352== by 0x5222E31: _IO_getline_info (iogetline.c:100) ==16352== by 0x52C9E4F: __fgets_chk (fgets_chk.c:45) ==16352== by 0x1ECF73: fgets (stdio2.h:202) ==16352== by 0x1ECF73: regex (regex.c:159) ==16352== by 0x15325E: acl_check_condition (acl.c:3947) ==16352== by 0x153D4F: acl_check_internal (acl.c:4428) ==16352== by 0x15476D: acl_check (acl.c:4742) ==16352== by 0x1B0266: receive_msg (receive.c:3689) ==16352== by 0x158513: handle_smtp_call (daemon.c:560) ==16352== by 0x15AB60: daemon_go (daemon.c:2809) ==16352== by 0x1750DD: main (exim.c:5138) ==16352== Address 0x595f6b0 is 32 bytes inside a block of size 32,792 free'd ==16352== at 0x4845543: free (vg_replace_malloc.c:974) ==16352== by 0x1CD47A: internal_store_free (store.c:1223) ==16352== by 0x1CDD82: internal_store_reset (store.c:888) ==16352== by 0x1CE689: store_reset_3 (store.c:923) ==16352== by 0x1ECFE3: regex (regex.c:172) ==16352== by 0x15325E: acl_check_condition (acl.c:3947) ==16352== by 0x153D4F: acl_check_internal (acl.c:4428) ==16352== by 0x15476D: acl_check (acl.c:4742) ==16352== by 0x1B0266: receive_msg (receive.c:3689) ==16352== by 0x158513: handle_smtp_call (daemon.c:560) ==16352== by 0x15AB60: daemon_go (daemon.c:2809) ==16352== by 0x1750DD: main (exim.c:5138) ==16352== Block was alloc'd at ==16352== at 0x48428DC: malloc (vg_replace_malloc.c:431) ==16352== by 0x1CD590: internal_store_malloc (store.c:1163) ==16352== by 0x1CD94B: pool_get (store.c:449) ==16352== by 0x1CE15F: store_get_3 (store.c:519) ==16352== by 0x1ECE9F: regex (regex.c:158) ==16352== by 0x15325E: acl_check_condition (acl.c:3947) ==16352== by 0x153D4F: acl_check_internal (acl.c:4428) ==16352== by 0x15476D: acl_check (acl.c:4742) ==16352== by 0x1B0266: receive_msg (receive.c:3689) ==16352== by 0x158513: handle_smtp_call (daemon.c:560) ==16352== by 0x15AB60: daemon_go (daemon.c:2809) ==16352== by 0x1750DD: main (exim.c:5138) ==16352==
(In reply to Marcin Mirosław from comment #26) > I don't know how to use valgrind... But I tried, is it good catch from log? > > ==16352== Invalid write of size 8 > ==16352== at 0x484D533: memmove (vg_replace_strmem.c:1400) > ==16352== by 0x5222E31: memcpy (string_fortified.h:29) > ==16352== by 0x5222E31: _IO_getline_info (iogetline.c:100) > ==16352== by 0x52C9E4F: __fgets_chk (fgets_chk.c:45) > ==16352== by 0x1ECF73: fgets (stdio2.h:202) > ==16352== by 0x1ECF73: regex (regex.c:159) Aha! Yes, that points right at my stupid coding. Next patch as soon as I can run the testsuite with it...
a173a4376d16. It's a somewhat indirect path to the crash in fclose() but possible.
I could not find the mentioned 5aacb69f5c8 in the repo, so I pulled in 6fcb3173d6 in order to make a173a4376d16 apply.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa7a1f384983f4d7158e7edbd9cab1a914140d28 commit fa7a1f384983f4d7158e7edbd9cab1a914140d28 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-02-15 08:27:25 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-02-15 08:28:27 +0000 mail-mta/exim-4.97.1-r4: update regex memory patch Include 6fcb3173d6 and 5aacb69f5c8 from upstream. Bug: https://bugs.gentoo.org/922780 Signed-off-by: Fabian Groffen <grobian@gentoo.org> ...exim-4.97.1-r3.ebuild => exim-4.97.1-r4.ebuild} | 0 .../files/exim-4.97.1-memory-usage-bug-3047.patch | 49 ++++++++++++++++------ 2 files changed, 36 insertions(+), 13 deletions(-)
So... Now mails are delivered to lda, great! But also valgrind shows: ==27422== Invalid read of size 8 ==27422== at 0x1ECD29: matcher (regex.c:81) ==27422== by 0x1ECF6E: regex (regex.c:160) ==27422== by 0x15325E: acl_check_condition (acl.c:3947) ==27422== by 0x153D4F: acl_check_internal (acl.c:4428) ==27422== by 0x15476D: acl_check (acl.c:4742) ==27422== by 0x1B0266: receive_msg (receive.c:3689) ==27422== by 0x158513: handle_smtp_call (daemon.c:560) ==27422== by 0x15AB60: daemon_go (daemon.c:2809) ==27422== by 0x1750DD: main (exim.c:5138) ==27422== Address 0x58b8db0 is 32,064 bytes inside a block of size 131,064 alloc'd ==27422== at 0x48428DC: malloc (vg_replace_malloc.c:431) ==27422== by 0x1CD590: internal_store_malloc (store.c:1163) ==27422== by 0x1CD94B: pool_get (store.c:449) ==27422== by 0x1CE15F: store_get_3 (store.c:519) ==27422== by 0x16CE9C: function_store_get (exim.c:70) ==27422== by 0x517956E: pcre2_match_8 (pcre2_match.c:6848) ==27422== by 0x16E0D6: regex_match_and_setup (exim.c:132) ==27422== by 0x197196: check_string (match.c:135) ==27422== by 0x197C58: match_check_list (match.c:748) ==27422== by 0x19927D: match_isinlist (match.c:1010) ==27422== by 0x152E12: acl_check_condition (acl.c:3831) ==27422== by 0x153D4F: acl_check_internal (acl.c:4428) ==27422== ==27422== Conditional jump or move depends on uninitialised value(s) ==27422== at 0x1ECD24: matcher (regex.c:76) ==27422== by 0x1ECF6E: regex (regex.c:160) ==27422== by 0x15325E: acl_check_condition (acl.c:3947) ==27422== by 0x153D4F: acl_check_internal (acl.c:4428) ==27422== by 0x15476D: acl_check (acl.c:4742) ==27422== by 0x1B0266: receive_msg (receive.c:3689) ==27422== by 0x158513: handle_smtp_call (daemon.c:560) ==27422== by 0x15AB60: daemon_go (daemon.c:2809) ==27422== by 0x1750DD: main (exim.c:5138) ==27422== Uninitialised value was created by a client request ==27422== at 0x1CD80C: pool_get (store.c:475) ==27422== by 0x1CE15F: store_get_3 (store.c:519) ==27422== by 0x16CE9C: function_store_get (exim.c:70) ==27422== by 0x517956E: pcre2_match_8 (pcre2_match.c:6848) ==27422== by 0x1ECD4C: matcher (regex.c:81) ==27422== by 0x1ECF6E: regex (regex.c:160) ==27422== by 0x15325E: acl_check_condition (acl.c:3947) ==27422== by 0x153D4F: acl_check_internal (acl.c:4428) ==27422== by 0x15476D: acl_check (acl.c:4742) ==27422== by 0x1B0266: receive_msg (receive.c:3689) ==27422== by 0x158513: handle_smtp_call (daemon.c:560) ==27422== by 0x15AB60: daemon_go (daemon.c:2809) ==27422== Is it something that needs attention?
(In reply to Marcin Mirosław from comment #31) > Is it something that needs attention? It is; thanks for spotting it. 44b3172e3694 addresses.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8b177cea39a5f4c6b96b698fb29266678ee19e0b commit 8b177cea39a5f4c6b96b698fb29266678ee19e0b Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-02-16 12:07:39 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-02-16 12:07:39 +0000 mail-mta/exim-4.97.1-r4: update regex memory patch Include 44b3172e3694 from upstream. Bug: https://bugs.gentoo.org/922780 Signed-off-by: Fabian Groffen <grobian@gentoo.org> .../{exim-4.97.1-r4.ebuild => exim-4.97.1-r5.ebuild} | 0 .../exim/files/exim-4.97.1-memory-usage-bug-3047.patch | 18 ++++++++++++------ 2 files changed, 12 insertions(+), 6 deletions(-)
valgrind, in my env, didn't detect any "Invalid read" or "write" now.
Is Exim now working OK otherwise too?
