Bug 157668 - using service start facility causes dbus-daemon SIGSEGV
using service start facility causes dbus-daemon SIGSEGV
Product: Fedora
Classification: Fedora
Component: dbus (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-05-13 12:20 EDT by Jason Vas Dias
Modified: 2013-03-05 22:43 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-15 21:56:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2005-05-13 12:20:02 EDT
Description of problem:

If a properly configured service (with /etc/dbus-1/system.d/${service}.conf
and /usr/share/dbus-1/services/${service}.service files) is not running and
a message is sent to the service destination, dbus-daemon should start the
service (version 0.32 did this fine).

Now, with version 0.33-2, sending a message to a service that is not running
causes dbus-daemon to get a SIGSEGV and exit.

This happens with the default .386 RPMs. I compiled dbus with debugging 
enabled to produce this dbus-daemon backtrace:  

$ gdb /usr/bin/dbus-daemon
GNU gdb Red Hat Linux (
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) set args --system --nofork
(gdb) run
Starting program: /usr/bin/dbus-daemon --system --nofork
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xf1f000
[Thread debugging using libthread_db enabled]
[New Thread -1208891712 (LWP 3397)]

( Now I send a message to a service that is not running, eg:
  # ps -ef | grep dhcdbd
  # /usr/bin/dbus-send --system --type=method_call --print-reply \
    --reply-timeout=20000 --dest=com.redhat.dhcp /com/redhat/dhcp/eth0 \

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208891712 (LWP 3397)]
0x0809e0e0 in _dbus_hash_table_remove_string (table=0x10, key=0x83cd0d0
    at dbus-hash.c:1269
1269      _dbus_assert (table->key_type == DBUS_HASH_STRING);
(gdb) bt
#0  0x0809e0e0 in _dbus_hash_table_remove_string (table=0x10, key=0x83cd0d0
    at dbus-hash.c:1269
#1  0x0804b445 in check_service_file (activation=0x83c2728, entry=0x83c23c0,
    error=0xbfd3e210) at activation.c:436
#2  0x0804cb85 in activation_find_entry (activation=0x83c2728,
service_name=0x83cccb0 "com.redhat.dhcp",
    error=0xbfd3e210) at activation.c:1275
#3  0x0804cc9b in bus_activation_activate_service (activation=0x83c2728,
    transaction=0x83cafc8, auto_activation=1, activation_message=0x83c0a20,
    service_name=0x83cccb0 "com.redhat.dhcp", error=0xbfd3e210) at activation.c:1324
#4  0x0805ae9b in bus_dispatch (connection=0x83c0ab0, message=0x83c0a20) at
#5  0x0805b13f in bus_dispatch_message_filter (connection=0x83c0ab0,
message=0x83c0a20, user_data=0x0)
    at dispatch.c:375
#6  0x08075e8e in dbus_connection_dispatch (connection=0x83c0ab0) at
#7  0x080bb7d8 in _dbus_loop_dispatch (loop=0x83bf350) at dbus-mainloop.c:482
#8  0x080bbf59 in _dbus_loop_iterate (loop=0x83bf350, block=1) at
#9  0x080bc01b in _dbus_loop_run (loop=0x83bf350) at dbus-mainloop.c:874
#10 0x0806b6e5 in main (argc=3, argv=0xbfd3e934) at main.c:405

Thus anyone can shut down dbus by sending a message to a service that is
not running, a security issue.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. send a message to a service that is not running

Actual results:

dbus-daemon exits with SIGSEGV

Expected results:
dbus-daemon should start the service and not exit
Comment 1 Jason Vas Dias 2005-05-13 15:43:50 EDT
 Not sure if this has anything to do with the problem, but now the 
 "Disconnected" message from  /org/freedesktop/DBus/Local that 
 connections get when the server goes down has a NULL sender -
 ie dbus_message_get_sender() returns NULL for this message .
 This is also not nice - it used to be the string 'org.freedesktop.DBus' -
 all applications that do not check for a NULL sender now also will get a SIGSEGV
 when dbus-daemon goes down.
Comment 2 John (J5) Palmieri 2005-05-13 19:08:43 EDT
According to the docs: 
const char* dbus_message_get_sender
Gets the unique name of the connection which originated this message, or NULL if
unknown or inapplicable. 

So one should always check for NULL.  As far as it used to send
org.freedesktop.DBus I'll have to check if this is a known change.
Comment 3 John (J5) Palmieri 2005-05-13 19:13:02 EDT
Just a note for myself so I don't forget, the crash was due to <servicedir> tag
being set in a policy file for the system bus.  This tag should only be set in
the master configuration file (i.e. system.conf or session.conf).  I should
check with upstream to make sure this is correct and add code to block the use
of <servicedir> tags in policy files.  

Taking this off the FC4 blocker list as the problem only occurs due to manual
Comment 4 Christian Iseli 2007-01-22 06:20:03 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Comment 5 Matthew Miller 2007-04-06 11:06:18 EDT
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest
this issue on a current release or on the latest development / test version, we
would appreciate that. Otherwise, this bug will be marked as CANTFIX one month
from now. Thanks for your help and for your patience.
Comment 6 petrosyan 2008-02-15 21:56:41 EST
Fedora Core 4 is no longer maintained.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

Note You need to log in before you can comment on or make changes to this bug.