Subject: nullmailer: "sendmail -bs" crashes: "traps: nullmailer-smtp[15059]
general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in
libc.so.6[7f0368c41000+157000]"
Date: Mon, 10 Jun 2024 14:26:17 +0200
Package: nullmailer
Version: 1:2.2+10~g7ed88a0-5
Severity: important
Control: found -1 1:2.2-3
Dear David,
I managed to reproducibly crash nullmailer-smtpd with a "general
protection fault" by calling the following command:
swaks -t [email protected] --pipe 'sendmail -bs'
This call produces the following output first:
=== Trying pipe to sendmail -bs...
=== Connected to sendmail -bs.
<- 220 nullmailer-smtpd ready
-> EHLO kote1.lugs.ch
<- 250 2.3.0 OK
-> MAIL FROM:<[email protected]>
<- 250 2.1.0 Sender accepted
-> RCPT TO:<[email protected]>
<- 250 2.1.5 Recipient accepted
-> DATA
<- 354 End your message with a period on a line by itself
-> Date: Mon, 10 Jun 2024 13:21:49 +0200
-> To: [email protected]
-> From: [email protected]
-> Subject: test Mon, 10 Jun 2024 13:21:49 +0200
-> Message-Id: <[email protected]>
-> X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/
->
-> This is a test mailing
->
->
-> .
*** Child process closed connection unexpectedly.
In /var/log/syslog I then find these log entries:
2024-06-10T13:21:49.468475+02:00 kote1 nullmailer: Trigger pulled.
2024-06-10T13:21:49.468687+02:00 kote1 nullmailer: Rescanning queue.
2024-06-10T13:21:49.468781+02:00 kote1 nullmailer: Starting delivery, 1 message(s) in queue.
2024-06-10T13:21:49.468793+02:00 kote1 nullmailer: Starting delivery: host: … protocol: smtp file: 1718018509.15060
2024-06-10T13:21:49.468802+02:00 kote1 nullmailer: From: <[email protected]> to: <[email protected]>
2024-06-10T13:21:49.468808+02:00 kote1 nullmailer: Message-Id: <[email protected]>
2024-06-10T13:21:49.471688+02:00 kote1 kernel: traps: nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9 sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]
2024-06-10T13:21:49.600127+02:00 kote1 nullmailer: smtp: Succeeded: 250 2.6.0 <[email protected]> [InternalId=172490181574991, Hostname=…] 1171 bytes in 0.106, 10.754 KB/sec Queued mail for delivery
2024-06-10T13:21:49.601067+02:00 kote1 nullmailer: Sent file.
2024-06-10T13:21:49.601118+02:00 kote1 nullmailer: Delivery complete, 0 message(s) remain.
The mail though seemed to end up in the queue. But since swaks exits
with non-zero due to "sendmail -bs" exits with non-zero, our Ansible
playbook fails, too.
I initially ran into this on a production host running Debian 11
Bullseye with different settings (hence marking as found in the version
in Bullseye), but I can still reproduce it on a test VM with Debian
Unstable where I installed nullmailer temporarily as well. (Bug report
resembles state on the latter.)
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages nullmailer depends on:
ii debconf [debconf-2.0] 1.5.86
ii libc6 2.38-12.1
ii libgnutls30t64 3.8.5-4
ii libstdc++6 14.1.0-1
nullmailer recommends no packages.
nullmailer suggests no packages.
-- debconf information:
* shared/mailname: kote1.lugs.ch
* nullmailer/relayhost:
* nullmailer/adminaddr: [email protected]
nullmailer/defaultdomain: lugs.ch
Acknowledgement sent
to David Bremner <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Tue, 11 Jun 2024 00:09:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Mon, 10 Jun 2024 21:04:32 -0300
Control: tag -1 confirmed
Axel Beckert <[email protected]> writes:
> Package: nullmailer
> Version: 1:2.2+10~g7ed88a0-5
> Severity: important
> Control: found -1 1:2.2-3
>
> Dear David,
>
> I managed to reproducibly crash nullmailer-smtpd with a "general
> protection fault" by calling the following command:
>
> swaks -t [email protected] --pipe 'sendmail -bs'
>
> This call produces the following output first:
I can duplicate this. I made a few (unsuccessful) attempts at localize
the error.
Attempt #1
If I run /usr/lib/sendmail -bs directly (or nullmailer-smtpd, which
amounts to the same thing, I think), and give exactly the same input, it
exits cleanly when I type QUIT. I also tried your swaks command on a
host where sendmail is postfix, and I see end of the transaction
-> .
<- 250 2.0.0 Ok: queued as 5EC225FB72
-> QUIT
<- 221 2.0.0 Bye
=== Connection closed with child process.
Attempt #2
swaks -t [email protected] --pipe 'gdb -batch -ex run -ex bt --args /usr/lib/sendmail -bs'
This actually runs without segfaulting, which made me think it might be
a memory error.
Attempt #3
swaks -t [email protected] --pipe 'valgrind /usr/lib/sendmail -bs'
This also runs without errors, so I'm out of ideas for the moment.
Acknowledgement sent
to Axel Beckert <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Tue, 11 Jun 2024 00:30:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Tue, 11 Jun 2024 02:27:26 +0200
Hi David,
David Bremner wrote:
> swaks -t [email protected] --pipe 'gdb -batch -ex run -ex bt --args /usr/lib/sendmail -bs'
>
> This actually runs without segfaulting, which made me think it might be
> a memory error.
There's one memory fix commit upstream in the master branch:
https://github.com/bruceg/nullmailer/commit/834e2eb6b7eac2648fc371c432a46e98d5966bb4
Could it be this one? At least "fdbuf.c" sounds as if it might be
involved in file descriptor thingies.
> Attempt #3
>
> swaks -t [email protected] --pipe 'valgrind /usr/lib/sendmail -bs'
>
> This also runs without errors,
Clearly a Heisenbug. ;-)
> so I'm out of ideas for the moment.
Maybe upstream has an idea if it's not that already made commit?
Regards, Axel
--
,''`. | Axel Beckert <[email protected]>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Acknowledgement sent
to David Bremner <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Tue, 11 Jun 2024 10:42:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Tue, 11 Jun 2024 07:40:09 -0300
Axel Beckert <[email protected]> writes:
> Hi David,
>
> David Bremner wrote:
>> swaks -t [email protected] --pipe 'gdb -batch -ex run -ex bt --args /usr/lib/sendmail -bs'
>>
>> This actually runs without segfaulting, which made me think it might be
>> a memory error.
>
> There's one memory fix commit upstream in the master branch:
> https://github.com/bruceg/nullmailer/commit/834e2eb6b7eac2648fc371c432a46e98d5966bb4
>
> Could it be this one? At least "fdbuf.c" sounds as if it might be
> involved in file descriptor thingies.
>
We're actually running a snapshot of master, so that commit is in
testing and unstable.
d
Acknowledgement sent
to David Bremner <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Wed, 12 Jun 2024 10:21:06 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Wed, 12 Jun 2024 07:19:02 -0300
David Bremner <[email protected]> writes:
>
> Attempt #3
>
> swaks -t [email protected] --pipe 'valgrind /usr/lib/sendmail -bs'
>
> This also runs without errors, so I'm out of ideas for the moment.
Attempt #4:
Rebuild with asan
make clean
make CXXFLAGS="-g -O1 -fsanitize=address"
make check
I don't know if this is coincidence, or actually meaningful, but the
test "Testing protocol success with smtp (stdin)" finds one memory leak.
220 OK
smtp: Succeeded: 220 OK
=================================================================
==3035435==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0x7f64762edd10 in strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:578
#1 0x563a16835173 in parse_option /home/bremner/software/debian/nullmailer/protocols/protocol.cc:116
#2 0x563a16835173 in parse_options /home/bremner/software/debian/nullmailer/protocols/protocol.cc:130
#3 0x563a16835173 in cli_main(int, char**) /home/bremner/software/debian/nullmailer/protocols/protocol.cc:138
SUMMARY: AddressSanitizer: 13 byte(s) leaked in 1 allocation(s).
Looking at the code there is indeed a leak, but it's hard to see how it
would lead to a crash.
Acknowledgement sent
to Bernhard Übelacker <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Fri, 21 Jun 2024 00:00:03 GMT) (full text, mbox, link).
On Wed, 12 Jun 2024 07:19:02 -0300 David Bremner <[email protected]> wrote:
> David Bremner <[email protected]> writes:
>
> >
> > Attempt #3
> >
> > swaks -t [email protected] --pipe 'valgrind /usr/lib/sendmail -bs'
> >
> > This also runs without errors, so I'm out of ideas for the moment.
>
> Attempt #4:
>
> Rebuild with asan
Hello David, hello Axel,
I tried if I can reproduce it and if rr-debugger might be able to record it.
And I received following replay session of the crashing process (PID 3025:
- It forks another process nullmailer-queue (in this example PID 3026)
- It calls waitpid on the PID 3026, but this returns -1 and errno=10 (seems to be ECHILD)
for some unknown reason.
- Therefore tries to write a error message, but the content and the pointer to cli_program
seem to get mixed up, therefore the strlen crashes.
Especially the third point is puzzling, I could not yet see why this pointer-content-mixup happens.
Kind regards,
Bernhard
root@debian:~# rr replay --debugger-option=-q -p 3025 -g 2000 bash-1
root@debian:~# swaks -t [email protected] --pipe 'sendmail -bs'
=== Trying pipe to sendmail -bs...
=== Connected to sendmail -bs.
Reading symbols from /root/.local/share/rr/bash-1/mmap_pack_11_nullmailer-smtpd...
Reading symbols from /usr/lib/debug/.build-id/42/8c5f859ee211c1dfa8accdc66572493c471db1.debug...
Really redefine built-in command "restart"? (y or n) [answered Y; input not from terminal]
Really redefine built-in command "jump"? (y or n) [answered Y; input not from terminal]
Remote debugging using 127.0.0.1:7992
--------------------------------------------------
---> Reached target process 3025 at event 2000.
--------------------------------------------------
Reading symbols from /usr/bin/../lib/rr/librrpreload.so...
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...
Reading symbols from /usr/lib/debug/.build-id/bc/40b1b7b2a76bc40d2372f4036be41bef33ef14.debug...
Reading symbols from /lib/x86_64-linux-gnu/libstdc++.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libstdc++.so.6)
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
Reading symbols from /usr/lib/debug/.build-id/2e/01923fea4ad9f7fa50fe24e0f3385a45a6cd1c.debug...
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...
Reading symbols from /usr/lib/debug/.build-id/6c/771bfaca294a4e3d85ada43b358bf6b49dcd2a.debug...
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/a9/700083811ae36d1017fe16ebe5657d59cdda0a.debug...
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...
(No debugging symbols found in /lib/x86_64-linux-gnu/libgcc_s.so.1)
BFD: warning: system-supplied DSO at 0x6fffd000 has a section extending past end of file
0x00007f0527d7f8b7 in __GI_mprotect () at ../sysdeps/unix/syscall-template.S:117
117 ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht gefunden.
(rr) set width 0
(rr) set pagination off
(rr) directory /home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib
Source directories searched: /home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib:$cdir:$cwd
(rr) directory /home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/src
Source directories searched: /home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/src:/home/benutzer/source/nullmailer/orig/nullmailer-2.2+10~g7ed88a0/lib:$cdir:$cwd
(rr) display/i $pc
1: x/i $pc
=> 0x7f0527d7f8b7 <__GI_mprotect+7>: cmp $0xfffffffffffff001,%rax
(rr) b fork
Breakpoint 1 at 0x7f05278f5560: file ./posix/fork.c, line 41.
(rr) cont
Continuing.
<- 220 nullmailer-smtpd ready
-> EHLO debian
<- 250 2.3.0 OK
-> MAIL FROM:<root@debian>
<- 250 2.1.0 Sender accepted
-> RCPT TO:<[email protected]>
<- 250 2.1.5 Recipient accepted
-> DATA
Breakpoint 1, __libc_fork () at ./posix/fork.c:41
41 ./posix/fork.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f05278f5560 <__libc_fork>: push %r14
(rr) finish
Run till exit from #0 __libc_fork () at ./posix/fork.c:41
0x00005639bd9132d5 in fork_exec::start (this=this@entry=0x7ffc4099cd00, args=args@entry=0x7ffc4099cca0, redirn=redirn@entry=3, redirs=redirs@entry=0x7ffc4099cc90) at ./lib/forkexec.cc:67
67 if ((pid = fork()) < 0)
1: x/i $pc
=> 0x5639bd9132d5 <_ZN9fork_exec5startEPPKciPi+501>: mov -0x58(%rbp),%rsi
Value returned is $1 = 3026
(rr) next
69 if (pid == 0) {
1: x/i $pc
=> 0x5639bd9132e3 <_ZN9fork_exec5startEPPKciPi+515>: jne 0x5639bd913306 <_ZN9fork_exec5startEPPKciPi+550>
(rr) print pid
$2 = 3026
(rr) b fork_exec::wait
Breakpoint 2 at 0x5639bd912ea0: file ./lib/forkexec.cc, line 121.
(rr) cont
Continuing.
<- 354 End your message with a period on a line by itself
-> Date: Fri, 21 Jun 2024 00:10:45 +0200
-> To: [email protected]
-> From: root@debian
-> Subject: test Fri, 21 Jun 2024 00:10:45 +0200
-> Message-Id: <20240621001045.003024@debian>
-> X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/
->
-> This is a test mailing
->
->
-> .
Breakpoint 2, fork_exec::wait (this=this@entry=0x7ffc4099cd00) at ./lib/forkexec.cc:121
121 {
1: x/i $pc
=> 0x5639bd912ea0 <_ZN9fork_exec4waitEv>: endbr64
(rr) next
122 if (pid > 0) {
1: x/i $pc
=> 0x5639bd912ec1 <_ZN9fork_exec4waitEv+33>: test %edi,%edi
(rr)
123 int status = wait_status();
1: x/i $pc
=> 0x5639bd912ef0 <_ZN9fork_exec4waitEv+80>: xor %edx,%edx
(rr) step
fork_exec::wait_status (this=0x7ffc4099cd00) at ./lib/forkexec.cc:112
112 if (waitpid(pid, &status, 0) == pid) {
1: x/i $pc
=> 0x5639bd912ef0 <_ZN9fork_exec4waitEv+80>: xor %edx,%edx
(rr) stepi
0x00005639bd912ef2 112 if (waitpid(pid, &status, 0) == pid) {
1: x/i $pc
=> 0x5639bd912ef2 <_ZN9fork_exec4waitEv+82>: lea 0x4(%rsp),%rsi
(rr)
0x00005639bd912ef7 112 if (waitpid(pid, &status, 0) == pid) {
1: x/i $pc
=> 0x5639bd912ef7 <_ZN9fork_exec4waitEv+87>: call 0x5639bd9110f0 <waitpid@plt>
(rr)
0x00005639bd9110f0 in waitpid@plt ()
1: x/i $pc
=> 0x5639bd9110f0 <waitpid@plt>: jmp *0x6e4a(%rip) # 0x5639bd917f40 <[email protected]>
(rr)
__GI___waitpid (pid=3026, stat_loc=0x7ffc4099ccb4, options=0) at ./posix/waitpid.c:38
38 ./posix/waitpid.c: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f05279109e0 <__GI___waitpid>: xor %ecx,%ecx
(rr) finish
Run till exit from #0 __GI___waitpid (pid=3026, stat_loc=0x7ffc4099ccb4, options=0) at ./posix/waitpid.c:38
0x00005639bd912efc in fork_exec::wait_status (this=0x7ffc4099cd00) at ./lib/forkexec.cc:112
112 if (waitpid(pid, &status, 0) == pid) {
1: x/i $pc
=> 0x5639bd912efc <_ZN9fork_exec4waitEv+92>: cmp (%rbx),%eax
Value returned is $3 = -1
(rr) print status
$4 = 0
(rr) print errno
$5 = 10
(rr) stepi
0x00005639bd912efe 112 if (waitpid(pid, &status, 0) == pid) {
1: x/i $pc
=> 0x5639bd912efe <_ZN9fork_exec4waitEv+94>: jne 0x5639bd913058 <_ZN9fork_exec4waitEv+440>
(rr)
0x00005639bd913058 in fork_exec::wait (this=this@entry=0x7ffc4099cd00) at ./lib/forkexec.cc:134
134 FAIL(name << " crashed or was killed");
1: x/i $pc
=> 0x5639bd913058 <_ZN9fork_exec4waitEv+440>: mov 0x20e1(%rip),%rbp # 0x5639bd915140 <cli_program>
(rr) x/2xg $rip + 0x20e1
0x5639bd915139: 0x6e00000000000000 0x656c69616d6c6c75
(rr) print cli_program
$6 = "nullmailer-smtpd"
(rr) stepi
fdobuf::operator<< (str=<optimized out>, this=<optimized out>) at ./fdbuf/fdobuf.h:59
59 write(str, strlen(str));
1: x/i $pc
=> 0x5639bd91305f <_ZN9fork_exec4waitEv+447>: lea 0x201f(%rip),%r12 # 0x5639bd915085
(rr)
0x00005639bd913066 in fdobuf::operator<< (str=0x6c69616d6c6c756e <error: Cannot access memory at address 0x6c69616d6c6c756e>, this=<optimized out>) at ./fdbuf/fdobuf.h:59
59 write(str, strlen(str));
1: x/i $pc
=> 0x5639bd913066 <_ZN9fork_exec4waitEv+454>: mov %rbp,%rdi
(rr)
0x00005639bd913069 59 write(str, strlen(str));
1: x/i $pc
=> 0x5639bd913069 <_ZN9fork_exec4waitEv+457>: call 0x5639bd9110a0 <strlen@plt>
(rr)
0x00005639bd9110a0 in strlen@plt ()
1: x/i $pc
=> 0x5639bd9110a0 <strlen@plt>: jmp *0x6e72(%rip) # 0x5639bd917f18 <[email protected]>
(rr)
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
65 ../sysdeps/x86_64/multiarch/strlen-avx2.S: Datei oder Verzeichnis nicht gefunden.
1: x/i $pc
=> 0x7f0527973dc0 <__strlen_avx2>: mov %edi,%eax
(rr) finish
Run till exit from #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76 in ../sysdeps/x86_64/multiarch/strlen-avx2.S
1: x/i $pc
=> 0x7f0527973dd9 <__strlen_avx2+25>: vpcmpeqb (%rdi),%ymm0,%ymm1
(rr) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1 0x00005639bd91306e in fdobuf::operator<< (str=0x6c69616d6c6c756e <error: Cannot access memory at address 0x6c69616d6c6c756e>, this=<optimized out>) at ./fdbuf/fdobuf.h:59
#2 fork_exec::wait (this=this@entry=0x7ffc4099cd00) at ./lib/forkexec.cc:125
#3 0x00005639bd91201f in DATA (param=...) at ./src/smtpd.cc:159
#4 DATA (param=...) at ./src/smtpd.cc:127
#5 0x00005639bd91144f in dispatch () at ./src/smtpd.cc:252
#6 main () at ./src/smtpd.cc:263
(rr) list 34
34
35 #define ERR(MSG) do{ ferr << cli_program << ": " << MSG << ": " << strerror(errno) << endl; } while(0)
36 #define FAIL(MSG) do{ ERR(MSG); return false; }while(0)
37
(rr) list fork_exec::wait
119
120 bool fork_exec::wait()
121 {
122 if (pid > 0) {
123 int status = wait_status();
124 if (status < 0)
125 FAIL("Error catching the return value from " << name);
126 if (WIFEXITED(status)) {
127 status = WEXITSTATUS(status);
128 if (status) {
129 ferr << cli_program << ": " << name << " failed: " << status << endl;
130 return false;
131 }
132 }
133 else
134 FAIL(name << " crashed or was killed");
135 }
136 return true;
137 }
(rr)
Acknowledgement sent
to Bernhard Übelacker <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Fri, 21 Jun 2024 09:03:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Fri, 21 Jun 2024 10:57:53 +0200
Am 21.06.24 um 01:57 schrieb Bernhard Übelacker:
> Especially the third point is puzzling, I could not yet see why this
> pointer-content-mixup happens.
Hello David, hello Axel,
I did some further tests and found following location where cli_program
is delared here:
./lib/cli++/cli++.h:35:extern const char* cli_program;
But the defintion looks a bit different:
./src/smtpd.cc:55:extern const char cli_program[] = "nullmailer-smtpd";
A package built with following change does no longer show this crash.
Kind regards,
Bernhard
--- src/smtpd.cc.orig 2023-04-22 19:06:36.000000000 +0200
+++ src/smtpd.cc 2024-06-21 10:45:25.982395298 +0200
@@ -53,5 +53,5 @@ static mystring sender;
static mystring recipients;
-extern const char cli_program[] = "nullmailer-smtpd";
+const char* cli_program = "nullmailer-smtpd";
static int readline()
Acknowledgement sent
to David Bremner <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Fri, 21 Jun 2024 18:51:04 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Fri, 21 Jun 2024 15:47:09 -0300
Bernhard Übelacker <[email protected]> writes:
> Am 21.06.24 um 01:57 schrieb Bernhard Übelacker:
>
>> Especially the third point is puzzling, I could not yet see why this
>> pointer-content-mixup happens.
>
>
> Hello David, hello Axel,
> I did some further tests and found following location where cli_program
> is delared here:
>
> ./lib/cli++/cli++.h:35:extern const char* cli_program;
>
> But the defintion looks a bit different:
>
> ./src/smtpd.cc:55:extern const char cli_program[] = "nullmailer-smtpd";
>
>
> A package built with following change does no longer show this crash.
>
> Kind regards,
> Bernhard
Hi Bernhard;
Thanks for the patch. This does seem to be progress, but I don't think
it completely fixes Axel's bug. At least for me I still see
-> .
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No child processes
nullmailer-smtpd: Error catching the return value from nullmailer-queue: No child processes
<** 451 4.3.0 Error returned from nullmailer-queue
and I get a non-zero exit code. I think the problem you found was
probably a crash during the reporting of the error message.
Acknowledgement sent
to Bernhard Übelacker <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Fri, 21 Jun 2024 22:45:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Bernhard Übelacker <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Sat, 22 Jun 2024 12:39:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Sat, 22 Jun 2024 14:34:19 +0200
Am 22.06.24 um 00:42 schrieb Bernhard Übelacker:
>I did some archaeology and found the issue got visible
>at 2017-12-30 in the Buster development cycle with the
>migration of nullmailer 1:2.1-5 into testing.
>
>
>
>debian-9-stretch: Connection closed with child process.
>testing https://snapshot.debian.org/archive/debian/20171229T045928Z/: Connection closed with child process.
>testing https://snapshot.debian.org/archive/debian/20171230T035716Z/: Child process closed connection unexpectedly. nullmailer (1:2.1-5) over (1:1.13-1.2) ...
>debian-10-buster: Child process closed connection unexpectedly.
Hello,
trying to go more into detail a git bisect
shows following upstream commit [1].
Kind regards,
Bernhard
https://snapshot.debian.org/package/nullmailer/1%3A1.13-1.2/: Connection closed with child process.
git checkout 1.13: Connection closed with child process.
1.13-68-g2e30750: Connection closed with child process.
1.13-69-g5850a49: Child process closed connection unexpectedly.
git checkout 2.0: Child process closed connection unexpectedly.
https://snapshot.debian.org/package/nullmailer/1%3A2.0-1/: Child process closed connection unexpectedly.
5850a49ade78d36ce33d70c28198b9cf2fb8fbdd is the first broken commit
commit 5850a49ade78d36ce33d70c28198b9cf2fb8fbdd
Author: Bruce Guenter <[email protected]>
Date: Fri Jan 15 11:40:38 2016 -0600
lib: Add fork_exec wrapper class for launching sub-programs
lib/Makefile.am | 1 +
lib/autoclose.h | 7 ++-
lib/forkexec.cc | 136 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
lib/forkexec.h | 32 +++++++++++++
src/inject.cc | 108 +++++++++++++-------------------------------
src/send.cc | 1 +
src/smtpd.cc | 63 +++++---------------------
7 files changed, 217 insertions(+), 131 deletions(-)
create mode 100644 lib/forkexec.cc
create mode 100644 lib/forkexec.h
[1] https://github.com/bruceg/nullmailer/commit/5850a49ade78d36ce33d70c28198b9cf2fb8fbdd
Acknowledgement sent
to Bernhard Übelacker <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Sat, 22 Jun 2024 22:33:04 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Sun, 23 Jun 2024 00:31:01 +0200
Hello David, hello Axel,
> I had hoped the expected behaviour might have been the error message 😉
Maybe it is the expected behaviour?
Following is the output of the last not crashing version 1.13
and the current version in testing 2.2+10~g7ed88a0 with the cli_program fix.
Both look quite similar except the previously crashing error message,
so this is maybe expected by upstream?
Kind regards,
Bernhard
1.13-1.2 || 2.2+10~g7ed88a0-5 + const char* cli_program = "nullmailer-smtpd";
||
root@debian:~# swaks -t [email protected] --pipe 'sendmail -bs' || root@debian:~# swaks -t [email protected] --pipe 'sendmail -bs'
=== Trying pipe to sendmail -bs... || === Trying pipe to sendmail -bs...
=== Connected to sendmail -bs. || === Connected to sendmail -bs.
<- 220 nullmailer-smtpd ready || <- 220 nullmailer-smtpd ready
-> EHLO debian || -> EHLO debian
<- 250 2.3.0 OK || <- 250 2.3.0 OK
-> MAIL FROM:<root@debian> || -> MAIL FROM:<root@debian>
<- 250 2.1.0 Sender accepted || <- 250 2.1.0 Sender accepted
-> RCPT TO:<[email protected]> || -> RCPT TO:<[email protected]>
<- 250 2.1.5 Recipient accepted || <- 250 2.1.5 Recipient accepted
-> DATA || -> DATA
<- 354 End your message with a period on a line by itself || <- 354 End your message with a period on a line by itself
-> Date: Sun, 23 Jun 2024 00:xx:xx +0200 || -> Date: Sun, 23 Jun 2024 00:xx:xx +0200
-> To: [email protected] || -> To: [email protected]
-> From: root@debian || -> From: root@debian
-> Subject: test Sun, 23 Jun 2024 00:xx:xx +0200 || -> Subject: test Sun, 23 Jun 2024 00:xx:xx +0200
-> Message-Id: <2024062300xxxx.0xxxxx@debian> || -> Message-Id: <2024062300xxxx.0xxxxx@debian>
-> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/ || -> X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/
-> || ->
-> This is a test mailing || -> This is a test mailing
-> || ->
|| ->
-> . || -> .
|| nullmailer-smtpd: Error catching the return value from nullmailer-queue: No child processes
|| nullmailer-smtpd: Error catching the return value from nullmailer-queue: No child processes
<** 451 4.3.0 Error checking return status from nullmailer-queue || <** 451 4.3.0 Error returned from nullmailer-queue
-> QUIT || -> QUIT
<- 221 2.0.0 Good bye || <- 221 2.0.0 Good bye
=== Connection closed with child process. || === Connection closed with child process.
root@debian:~# || root@debian:~#
Acknowledgement sent
to David Bremner <[email protected]>:
Extra info received and forwarded to list. Copy sent to David Bremner <[email protected]>.
(Tue, 25 Jun 2024 10:33:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1072922: nullmailer: "sendmail -bs" crashes: "traps:
nullmailer-smtp[15059] general protection fault ip:7f0368d73dd9
sp:7fff5e3d7088 error:0 in libc.so.6[7f0368c41000+157000]"
Date: Tue, 25 Jun 2024 07:31:23 -0300
Bernhard Übelacker <[email protected]> writes:
> Hello David, hello Axel,
>
>
>> I had hoped the expected behaviour might have been the error message 😉
>
> Maybe it is the expected behaviour?
>
> Following is the output of the last not crashing version 1.13
> and the current version in testing 2.2+10~g7ed88a0 with the cli_program fix.
>
> Both look quite similar except the previously crashing error message,
> so this is maybe expected by upstream?
Or it's just an old bug?
It still looks like pretty strange behaviour to me. Does (nullmailer's
version of) sendmail -bs always return a non-zero exit code, or just in
some circumstances?