SBUS:A core dump occurs when dbus_server_get_address()

[HelloCarry]

Hi @alexey-tikhonov
As noted in the previous issue #6450, we encountered a similar croemdump on sssd 2-6.
The reason is that the input parameter is NULL when the DBUS API:dbus_server_get_address() is invoked. However, the DBUS processing logic coredump when the input parameter is NULL,I'd like to ask if it's necessary to validate the input parameters before calling dbus_server_get_address.

[New LWP 98099]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/sssd -i --logger=files'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000ffff96757ca8 in ?? () from /usr/lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install cyrus-sasl-lib-2.1.27-13.h7.eulerosv2r11.aarch64 ding-libs-0.6.1-42.h1.eulerosv2r11.aarch64 e2fsprogs-1.46.4-7.h12.eulerosv2r11.aarch64 glibc-2.34-70.h35.eulerosv2r11.aarch64 keyutils-libs-1.6.3-3.h3.eulerosv2r11.aarch64 libcap-2.61-1.h3.eulerosv2r11.aarch64 libgcrypt-1.9.4-1.h4.eulerosv2r11.aarch64 libgpg-error-1.43-1.eulerosv2r11.aarch64 libldb-2.4.1-1.h1.eulerosv2r11.aarch64 libnl3-3.5.0-4.h5.eulerosv2r11.aarch64 libselinux-3.3-1.h3.eulerosv2r11.aarch64 libtalloc-2.3.3-1.eulerosv2r11.aarch64 libtdb-1.4.5-1.eulerosv2r11.aarch64 libtevent-0.11.0-1.h1.eulerosv2r11.aarch64 libunistring-0.9.10-8.eulerosv2r11.aarch64 libxcrypt-4.4.26-2.h2.eulerosv2r11.aarch64 lmdb-0.9.29-1.h1.eulerosv2r11.aarch64 lz4-1.9.3-2.h1.eulerosv2r11.aarch64 openldap-2.6.0-2.h9.eulerosv2r11.aarch64 openssl-libs-1.1.1m-2.h20.eulerosv2r11.aarch64 pcre2-10.39-1.h3.eulerosv2r11.aarch64 popt-1.18-1.h3.eulerosv2r11.aarch64 systemd-libs-249-16.h38.eulerosv2r11.aarch64 xz-libs-5.2.5-2.h1.eulerosv2r11.aarch64 zlib-1.2.11-19.h5.eulerosv2r11.aarch64
(gdb) bt
#0  0x0000ffff96757ca8 in ?? () from /usr/lib64/libc.so.6
#1  0x0000ffff96713cbc in raise () from /usr/lib64/libc.so.6
#2  0x0000ffff96701d2c in abort () from /usr/lib64/libc.so.6
#3  0x0000ffff96a54a50 in _dbus_abort () at dbus-sysdeps.c:93
#4  0x0000ffff96a4a080 in _dbus_warn_check_failed (
    format=format@entry=0xffff96a5aa18 "arguments to %s() were incorrect, assertion \"%s\" failed in file %s line %d.\nThis is normally a bug in some application using the D-Bus library.\n") at dbus-internals.c:281
#5  0x0000ffff96a4a878 in _dbus_warn_return_if_fail (function=function@entry=0xffff96a59f80 <__func__.8> "dbus_server_get_address",
    assertion=assertion@entry=0xffff96a59ec8 "server != NULL", file=file@entry=0xffff96a59e78 "dbus-server.c", line=line@entry=835) at dbus-internals.c:936
#6  0x0000ffff96a416d0 in dbus_server_get_address (server=server@entry=0x0) at dbus-server.c:835
#7  0x0000ffff96b23934 in sbus_server_socket_listen (socket_address=<optimized out>) at src/sbus/server/sbus_server.c:136
#8  sbus_server_setup_dbus (ev=<optimized out>, _symlink=<synthetic pointer>, gid=0, uid=0, use_symlink=false,
    address=0xffff96b2f808 "src/sbus/server/sbus_server.c", mem_ctx=0xaaab1d89d140) at src/sbus/server/sbus_server.c:337
#9  sbus_server_create (mem_ctx=mem_ctx@entry=0xaaab1d89d0d0, ev=ev@entry=0xaaab1d838d50,
    address=address@entry=0xaaaae6bee838 "unix:path=/var/lib/sss/pipes/private/sbus-monitor", use_symlink=use_symlink@entry=false,
    max_connections=max_connections@entry=100, uid=uid@entry=0, gid=gid@entry=0, on_conn_cb=on_conn_cb@entry=0x0, on_conn_data=on_conn_data@entry=0x0)
    at src/sbus/server/sbus_server.c:660
#10 0x0000ffff96b10648 in sbus_server_create_and_connect_send (mem_ctx=<optimized out>, ev=0xaaab1d838d50, dbus_name=0xaaaae6becc48 "sssd.monitor",
    last_activity_time=0x0, address=0xaaaae6bee838 "unix:path=/var/lib/sss/pipes/private/sbus-monitor", use_symlink=false, max_connections=100, uid=0, gid=0,
    on_conn_cb=0x0, on_conn_data=0x0) at src/sbus/connection/sbus_connection_connect.c:362
#11 0x0000aaaae6be5930 in monitor_process_init (config_file=<optimized out>, ctx=0xaaab1d7f3210) at src/monitor/monitor.c:1988
#12 main (argc=<optimized out>, argv=<optimized out>) at src/monitor/monitor.c:2580

root@localhost ~]# sssd --version
2.6.1

[alexey-tikhonov]

Hi @HelloCarry,

sorry for the delay.

The reason is that the input parameter is NULL when the DBUS API:dbus_server_get_address() is invoked. However, the DBUS processing logic coredump when the input parameter is NULL,I'd like to ask if it's necessary to validate the input parameters before calling dbus_server_get_address.

It's actually tested:

sssd/src/sbus/server/sbus_server.c

Line 129 in 02bdef7

if (server == NULL) {

Do you see corresponding "Unable to start a D-Bus server at ..." in the /var/log/sssd/sssd.log?

It should return at this point, of course. But that won't change much: instead of abort() in libdbus monitor would just refuse to start.

The real question: why did dbus_server_listen() fail? Details of error message "Unable to start a D-Bus server at ..." could help to understand this.

[HelloCarry]

Hi @alexey-tikhonov
Sorry, my environment has been destroyed. If the coredump occurs again, i will check the information in the sssd.log file.

[alexey-tikhonov]

Pushed PR: #6502

• master
  • 2932645 - SBUS: don't call dbus_server_get_address(NULL)