Samba dump (useless) core

Andrea Venturoli ml at netfence.it
Sat May 18 14:14:46 UTC 2019


On 5/8/19 1:44 PM, Jan Beich wrote:
Hello.

While I am by no means at the end of this, I'll post some updates.





 > "stack overflow detected" messages are part of -fstack-protector*.
 > Recently, ports/ default changed to -strong in order to follow base/.
 >
 > https://svnweb.freebsd.org/changeset/ports/499897

Reading the description of -fstack-protector vs 
-fstack-protector-strong, it shouldn't make any difference in this function.
I tried "SSP_CFLAGS?=	-fstack-protector" for confirmation and the canary 
is still there.
So that changeset cannot be the culprit.

I do no dare trying "SSP_UNSAFE=	yes", because, in case it's really a 
buffer overflow, I prefer a core to undefined behaviour on production 
servers!
Perhaps it's lack of imagination on my part, but I fail to see how SSP 
could give a false positive...
Besides there are other hints which make me suspect a buffer overflow is 
really happening.





 > If neither DEBUG port option nor WITH_DEBUG make variable provide symbols
 > then file a bug.

The DEBUG option is there and works (using base GDB had me think 
otherwise, but after switching to devel/gdb I can see debug info).

However, ports seem to compile with -O2, which sometimes makes it hard 
to unterstand what's going on; so I added "CFLAGS= 
  -O0" to Makefile.





Putting that binary (with -O0) in production on one server has halted 
the stream of cores, at least for now: I had about one core per minute 
before; now it has been working fine for 30 minutes.
The other server which shows this problem is not dumping cores right now.

I'm not saying it's solved, however, since these dumps in the past have 
stopped appearing several times, and later started happening again; so 
I'll have to keep an eye on this.

(My wild guess, but I'm not sure, is that this happens when a client 
needs to change its trust password: it tries again and again, and if it 
eventually succeeds, then I don't get any more core until another client 
needs this).





 > In addition to debug symbols try building with -fsanitize=address in
 > order to save time finding a place where the overflow occurs.

I wanted to try this, but ended up with an error during "make configure":
----------------------------------------
Checking simple C program
==>
#define CONFIG_H_IS_FROM_SAMBA 1
#define _SAMBA_BUILD_ 4
#define HAVE_CONFIG_H 1
#define SRCDIR "/usr/ports/net/samba48/work/samba-4.8.12"
#define HAVE_SYS_UTSNAME_H 1
/* #undef SYSTEM_UNAME_SYSNAME */
/* #undef SYSTEM_UNAME_MACHINE */
/* #undef SYSTEM_UNAME_RELEASE */
/* #undef SYSTEM_UNAME_VERSION */
#define HAVE_STDIO_H 1
#include <stdio.h>

  int main(void) { printf("hello world"); return 0; }

<==
[1/2] Compiling test.c
['cc', '-O2', '-pipe', '-fsanitize=address', '-DLIBICONV_PLUG', 
'-fno-color-diagnostics', '-fstack-protector-strong', 
'-DLDAP_DEPRECATED', '-isystem', '/usr/local/include', 
'-fno-strict-aliasing', '-fno-omit-frame-pointer', 
'-I/usr/ports/net/samba48/work/samba-4.8.12/lib/replace/../../buildtools/wafsamba', 
'-MD', '-Idefault', '-I..', '-Idefault', '-I..', '-DLIBICONV_PLUG', 
'-isystem', '/usr/local/include', '-D_SAMBA_BUILD_=4', 
'-DHAVE_CONFIG_H=1', '../test.c', '-c', '-o', 'default/test_1.o']
[2/2] Linking default/testprog
default/test_1.o: In function `asan.module_ctor':
test.c:(.text+0x22): undefined reference to `__asan_init'
test.c:(.text+0x27): undefined reference to 
`__asan_version_mismatch_check_v8'
test.c:(.text+0x36): undefined reference to `__asan_register_globals'
default/test_1.o: In function `asan.module_dtor':
test.c:(.text+0x4c): undefined reference to `__asan_unregister_globals'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
['cc', 'default/test_1.o', '-o', 
'/usr/ports/net/samba48/work/samba-4.8.12/bin/.conf_check_0/testbuild/default/testprog', 
'-fstack-protector-strong', '-L/usr/local/lib']





  bye & Thanks
	av.


More information about the freebsd-ports mailing list