Bug 160676 - dbus_pin_helper crashes hcid
dbus_pin_helper crashes hcid
Status: CLOSED DUPLICATE of bug 183145
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
:
: 162836 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-16 11:35 EDT by Stefan Becker
Modified: 2007-11-30 17:11 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 10:55:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hcid 2.19-1 trace (1.92 KB, text/plain)
2005-08-09 14:12 EDT, Christoph Wickert
no flags Details
Unref your pending call (278 bytes, patch)
2005-08-24 14:06 EDT, John (J5) Palmieri
no flags Details | Diff

  None (edit)
Description Stefan Becker 2005-06-16 11:35:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Firefox/1.0.4

Description of problem:
By default dbus_pin_helper is configured in /etc/bluetooth/hcid.conf. When hcid tries to request a PIN while pairing a BT device it crashes

Version-Release number of selected component (if applicable):
bluez-utils-2.15-7

How reproducible:
Always

Steps to Reproduce:
1. Base FC4 installation, dbus_pin_helper not commented out in /etc/bluetooth/hcid.conf, new unpaired BT device
2. service bluetooth start
3. rfcomm connect 0 00:02:EE:93:9F:C8 1

Actual Results:  # ps -efw | fgrep hcid
root      8480     1  0 06:35 ?        00:00:00 hcid: processing events

# tail /var/log/messages
...
Jun 16 06:35:24 baraddur hcid[8480]: Bluetooth HCI daemon
Jun 16 06:35:24 baraddur hcid[8480]: Starting security manager 0
Jun 16 06:35:24 baraddur sdpd[8484]: Bluetooth SDP daemon

 ---> execute "rfcomm connect 0 00:02:EE:93:9F:C8 1"

# ps -efw | fgrep hcid
root      8499  8363  0 06:35 pts/5    00:00:00 fgrep hcid

# tail /var/log/messages
...
Jun 16 06:35:24 baraddur hcid[8480]: Bluetooth HCI daemon
Jun 16 06:35:24 baraddur hcid[8480]: Starting security manager 0
Jun 16 06:35:24 baraddur sdpd[8484]: Bluetooth SDP daemon
Jun 16 06:35:41 baraddur hcid[8480]: link_key_request (sba=00:0A:3A:58:BC:54, 
dba=00:02:EE:93:9F:C8)
Jun 16 06:35:41 baraddur hcid[8480]: pin_code_request (sba=00:0A:3A:58:BC:54, 
dba=00:02:EE:93:9F:C8)


Expected Results:  PIN requestor should pop up

Additional info:

More information when hcid executed not as daemon:

# hcid -n -f /etc/bluetooth/hcid.conf
hcid[8524]: Bluetooth HCI daemon
hcid[8524]: Starting security manager 0

 ---> execute "rfcomm connect 0 00:02:EE:93:9F:C8 1"

hcid[8524]: link_key_request (sba=00:0A:3A:58:BC:54, dba=00:02:EE:93:9F:C8)
hcid[8524]: pin_code_request (sba=00:0A:3A:58:BC:54, dba=00:02:EE:93:9F:C8)
8524: arguments to dbus_type_is_basic() were incorrect, assertion 
"_dbus_type_is_valid (typecode) || typecode == DBUS_TYPE_INVALID" failed in 
file dbus-signature.c line 259.
This is normally a bug in some application using the D-BUS library.
type unknown isn't supported yet in dbus_message_append_args_valist
*** buffer overflow detected ***: hcid: processing events terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x1ef565]
hcid: processing events[0x490e8b]
/usr/lib/libdbus-1.so.1[0xe09155]
/usr/lib/libdbus-1.so.1[0xde949e]
/usr/lib/libdbus-1.so.1(dbus_connection_dispatch+0x20a)[0xdedf44]
hcid: processing events[0x4909c0]
hcid: processing events[0x4908b0]
hcid: processing events(main+0x4c5)[0x48cfef]
/lib/libc.so.6(__libc_start_main+0xc6)[0x125de6]
hcid: processing events[0x48c071]
======= Memory map: ========
00111000-00235000 r-xp 00000000 03:03 787576     /lib/libc-2.3.5.so
00235000-00237000 r-xp 00124000 03:03 787576     /lib/libc-2.3.5.so
00237000-00239000 rwxp 00126000 03:03 787576     /lib/libc-2.3.5.so
00239000-0023b000 rwxp 00239000 00:00 0
002dd000-002f7000 r-xp 00000000 03:03 787546     /lib/ld-2.3.5.so
002f7000-002f8000 r-xp 00019000 03:03 787546     /lib/ld-2.3.5.so
002f8000-002f9000 rwxp 0001a000 03:03 787546     /lib/ld-2.3.5.so
0048a000-00494000 r-xp 00000000 03:03 2497599    /usr/sbin/hcid
00494000-00495000 rwxp 00009000 03:03 2497599    /usr/sbin/hcid
00ce5000-00ce6000 r-xp 00ce5000 00:00 0
00ddd000-00e46000 r-xp 00000000 03:03 2497849    /usr/lib/libdbus-1.so.1.0.0
00e46000-00e4b000 rwxp 00069000 03:03 2497849    /usr/lib/libdbus-1.so.1.0.0
00f2b000-00f34000 r-xp 00000000 03:03 
787580     /lib/libgcc_s-4.0.0-20050520.so.1
00f34000-00f35000 rwxp 00009000 03:03 
787580     /lib/libgcc_s-4.0.0-20050520.so.1
00f6c000-00f78000 r-xp 00000000 03:03 
2494741    /usr/lib/libbluetooth.so.1.0.15
00f78000-00f79000 rwxp 0000c000 03:03 
2494741    /usr/lib/libbluetooth.so.1.0.15
00f7e000-00f90000 r-xp 00000000 03:03 787587     /lib/libnsl-2.3.5.so
00f90000-00f91000 r-xp 00011000 03:03 787587     /lib/libnsl-2.3.5.so
00f91000-00f92000 rwxp 00012000 03:03 787587     /lib/libnsl-2.3.5.so
00f92000-00f94000 rwxp 00f92000 00:00 0
084c0000-084e1000 rw-p 084c0000 00:00 0          [heap]
b7f2b000-b7f2d000 rw-p b7f2b000 00:00 0
bfb2b000-bfb41000 rw-p bfb2b000 00:00 0          [stack]
Aborted


When dbus_pin_helper is commented out hcid uses bluepin/bluez-ping PIN helpers which work OK
Comment 1 Bastien Nocera 2005-07-22 08:19:32 EDT
Which version of bluez-pin and dbus are you using on this machine?
Could you please follow the instructions at
http://fedora.linux.duke.edu/wiki/StackTraces to gather a backtrace on hcid?
Comment 2 Christoph Wickert 2005-07-22 16:13:18 EDT
Same here. Including a backtrace.

# rpm -q bluez-utils bluez-libs bluez-pin dbus
bluez-utils-2.15-7
bluez-libs-2.15-1
bluez-pin-0.24-2
dbus-0.33-3

HCI daemon ver 2.15

gdb hcid
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
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) run -n
Starting program: /usr/sbin/hcid -n
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x29b000
hcid[18412]: Bluetooth HCI daemon
Detaching after fork from child process 18416.
Detaching after fork from child process 18417.
hcid[18412]: Starting security manager 0
hcid[18412]: pin_code_request (sba=00:10:DC:AF:F7:70, dba=00:0F:DE:1C:B4:DD)
18412: arguments to dbus_type_is_basic() were incorrect, assertion
"_dbus_type_is_valid (typecode) || typecode == DBUS_TYPE_INVALID" failed in file
dbus-signature.c line 259.
This is normally a bug in some application using the D-BUS library.
type unknown isn't supported yet in dbus_message_append_args_valist
*** buffer overflow detected ***: hcid: processing events terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0x200565]
hcid: processing events[0xab7e8b]
/usr/lib/libdbus-1.so.1[0xe57155]
/usr/lib/libdbus-1.so.1[0xe3749e]
/usr/lib/libdbus-1.so.1(dbus_connection_dispatch+0x20a)[0xe3bf44]
hcid: processing events[0xab79c0]
hcid: processing events[0xab78b0]
hcid: processing events(main+0x4c5)[0xab3fef]
/lib/libc.so.6(__libc_start_main+0xc6)[0x136de6]
hcid: processing events[0xab3071]
======= Memory map: ========
00122000-00246000 r-xp 00000000 03:03 2715551    /lib/libc-2.3.5.so
00246000-00248000 r-xp 00124000 03:03 2715551    /lib/libc-2.3.5.so
00248000-0024a000 rwxp 00126000 03:03 2715551    /lib/libc-2.3.5.so
0024a000-0024c000 rwxp 0024a000 00:00 0
0029b000-0029c000 r-xp 0029b000 00:00 0
00ab1000-00abb000 r-xp 00000000 03:03 1642413    /usr/sbin/hcid
00abb000-00abc000 rwxp 00009000 03:03 1642413    /usr/sbin/hcid
00bc5000-00bce000 r-xp 00000000 03:03 2724376    /lib/libgcc_s-4.0.0-20050520.so.1
00bce000-00bcf000 rwxp 00009000 03:03 2724376    /lib/libgcc_s-4.0.0-20050520.so.1
00c0a000-00c24000 r-xp 00000000 03:03 2715550    /lib/ld-2.3.5.so
00c24000-00c25000 r-xp 00019000 03:03 2715550    /lib/ld-2.3.5.so
00c25000-00c26000 rwxp 0001a000 03:03 2715550    /lib/ld-2.3.5.so
00e2b000-00e94000 r-xp 00000000 03:03 1639043    /usr/lib/libdbus-1.so.1.0.0
00e94000-00e99000 rwxp 00069000 03:03 1639043    /usr/lib/libdbus-1.so.1.0.0
00f23000-00f2f000 r-xp 00000000 03:03 1653147   
/usr/lib/libbluetooth.so.1.0.1500f2f000-00f30000 rwxp 0000c000 03:03 1653147   
/usr/lib/libbluetooth.so.1.0.1500f72000-00f84000 r-xp 00000000 03:03 2715558   
/lib/libnsl-2.3.5.so
00f84000-00f85000 r-xp 00011000 03:03 2715558    /lib/libnsl-2.3.5.so
00f85000-00f86000 rwxp 00012000 03:03 2715558    /lib/libnsl-2.3.5.so
00f86000-00f88000 rwxp 00f86000 00:00 0
08b5e000-08b7f000 rw-p 08b5e000 00:00 0          [heap]
b7f8a000-b7f8c000 rw-p b7f8a000 00:00 0
bfc8d000-bfca3000 rw-p bfc8d000 00:00 0          [stack]

Program received signal SIGABRT, Aborted.
0x0029b402 in __kernel_vsyscall ()
(gdb) bt
#0  0x0029b402 in __kernel_vsyscall ()
#1  0x0014a1f8 in raise () from /lib/libc.so.6
#2  0x0014b948 in abort () from /lib/libc.so.6
#3  0x0017f52a in __libc_message () from /lib/libc.so.6
#4  0x00200565 in __chk_fail () from /lib/libc.so.6
#5  0x00ab7e8b in reply_handler_function (call=0x0, user_data=0x8b60950)
    at dbus.c:91
#6  0x00e57155 in dbus_pending_call_get_data () from /usr/lib/libdbus-1.so.1
#7  0x00e3749e in dbus_connection_has_messages_to_send ()
   from /usr/lib/libdbus-1.so.1
#8  0x00e3bf44 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.1
#9  0x00ab79c0 in watch_func (chan=0x8b60288, cond=G_IO_IN, data=0x0)
    at dbus.c:169
#10 0x00ab78b0 in g_main_loop_run (loop=0x8b5e038) at glib-ectomy.c:163
#11 0x00ab3fef in main (argc=2, argv=0xbfca0984, env=0x0) at main.c:598
(gdb) quit
The program is running.  Exit anyway? (y or n) y
Comment 3 Bastien Nocera 2005-07-27 09:54:50 EDT
*** Bug 162836 has been marked as a duplicate of this bug. ***
Comment 4 Bastien Nocera 2005-07-27 09:55:33 EDT
From bug 162836, comment 2:
there are a couple of issues with the D-Bus patch.  

First, you are leaking in reply_handler_function.  You need to unref your
pending call.

Second, in hcid_dbus_request_pin, you pass an iterator to
dbus_message_append_args.  This causes the crash described in this bug report. 
dbus_message_append_args only take a message and a list of type, value pairs. 
You only need to use an iterator when dealing with dbus_message_iter_* methods.
Comment 5 David Woodhouse 2005-08-09 12:57:54 EDT
Please try bluez-libs-2.19-1 and bluez-utils-2.19-1 from rawhide. 
Comment 6 Christoph Wickert 2005-08-09 14:10:39 EDT
I have rebuild bluez-libs-2.19-1.src.rpm and bluez-utils-2.19-1.scr.rpm, for I
did not want to upgrade all my glibc packages. Hcid is still crashing. Including
a new trace.

hcid -n
hcid[3766]: Bluetooth HCI daemon
hcid[3766]: Starting security manager 0
hcid[3766]: pin_code_request (sba=00:10:DC:AF:F7:70, dba=00:0F:DE:1C:B4:DD)
Speicherzugriffsfehler
Comment 7 Christoph Wickert 2005-08-09 14:12:06 EDT
Created attachment 117585 [details]
hcid 2.19-1 trace
Comment 8 John (J5) Palmieri 2005-08-09 15:08:48 EDT
The relevant call here is:

dbus_message_append_args(message, DBUS_TYPE_BOOLEAN, &ci->out,
                        DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE,
                        &ci->bdaddr, sizeof(bdaddr_t), DBUS_TYPE_INVALID);

I think the problem is &ci->bdaddr.  The dbus docs state this as the format for
appending fixed arrays:

const dbus_int32_t array[] = { 1, 2, 3 };
const dbus_int32_t *v_ARRAY = array;
DBUS_TYPE_ARRAY, DBUS_TYPE_INT32, &v_ARRAY, 3

So above should look more like:
const bdaddr_t *v_bdaddr = ci->bdaddr;
DBUS_TYPE_ARRAY, DBUS_TYPE_BYTE, &v_bdaddr, sizeof(bdaddr_t)
Comment 9 David Woodhouse 2005-08-24 11:24:34 EDT
Does the patch in bluez-utils-2.19-2 look OK?
Comment 10 John (J5) Palmieri 2005-08-24 11:42:52 EDT
Looks good to me
Comment 11 David Woodhouse 2005-08-24 11:51:40 EDT
Thanks. In comment #2, Bastien says "you are leaking in reply_handler_function.
 You need to unref your pending call."

My dbus-fu is weak. If that's still a problem in the 2.19 code, please could you
elaborate so I can fix it? Preferably in 'diff -u' form :)
Comment 12 Bastien Nocera 2005-08-24 12:04:00 EDT
Don't shoot the messenger, John said that in the other bug. I have no idea what
he's on about ;)
Comment 13 John (J5) Palmieri 2005-08-24 14:06:26 EDT
Created attachment 118084 [details]
Unref your pending call

Here you go
Comment 14 Thomas Antony 2005-11-27 17:15:58 EST
My hcid is still crashing so i think nothing had happened so far.
Can we get this bug fixed somehow?
Comment 15 Daniel Roesen 2005-12-12 19:47:03 EST
Thomas: still crashing with rawhide bluez-utils?
Comment 16 Thomas Antony 2005-12-13 03:29:42 EST
bluez-utils and the other bluez rpm's in rawhide have got different
dependencies, which are not available for FC4.

Failed dependencies:
        bind-libs = 28:9.3.2rc1-1.1 is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libc.so.6(GLIBC_2.4)(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libcrypto.so.6()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libdns.so.21()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        libisc.so.11()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        liblwres.so.9()(64bit) is needed by bind-utils-9.3.2rc1-1.1.x86_64
        bind-utils = 24:9.3.1-14_FC4 is needed by (installed)
bind-9.3.1-14_FC4.x86_64

If there are bluez rpm's for FC4 in the testing repo, i will install them and
give a feedback, but i will not upgrade FC4 to rawhide.
Comment 17 Jarmo Rosenqvist 2006-01-10 15:31:18 EST
still having problems with current rawhide
bluez-libs-2.22-1.1
bluez-pin-0.24-3.1
bluez-utils-2.22-2.1

bluez-pin --dbus gives error  9334: arguments to
dbus_message_iter_get_fixed_array() were  incorrect, assertion
"dbus_type_is_fixed (_dbus_type_reader_get_current_type (& real->u.reader))"
failed in file dbus-message.c line 1741.
This is normally a bug in some application using the D-BUS library.

hcid output to /var/log/messages
Jan 10 21:52:28 localhost hcid[9477]: pin_code_request (sba=00:10:C6:62:97:8B,
dba=00:11:9F:6C:4D:24)
Jan 10 21:52:28 localhost hcid[9477]: org.bluez.Error.WrongArgs: Byte array
expected, other type given

Comment 18 Stefan Becker 2006-02-25 04:07:35 EST
Still not fixed with latest stuff under FC5test3:

bluez-pin-0.24-3.2.1
bluez-utils-2.22-2.2.1
bluez-libs-2.25-1
dbus-0.60-7.2

3635: arguments to dbus_message_iter_get_fixed_array() were incorrect, assertion
"dbus_type_is_fixed (_dbus_type_reader_get_current_type (&real->u.reader))"
failed in file dbus-message.c line 1741.
This is normally a bug in some application using the D-BUS library.

Feb 25 01:07:01 baraddur hcid[3673]: pin_code_request (sba=00:0A:3A:58:BC:54,
dba=00:07:A4:10:30:C6)
Feb 25 01:07:01 baraddur hcid[3673]: org.bluez.Error.WrongArgs: Byte array
expected, other type given
Comment 19 David Woodhouse 2006-02-28 12:24:53 EST
rawhide now has bluez-utils-2.25. Please retest.
Comment 20 Stefan Becker 2006-03-10 22:25:17 EST
Still the same problem:

dbus-0.61-3
bluez-utils-2.25-3
bluez-pin-0.24-3.2.1
bluez-libs-2.25-1
selinux-policy-targeted-2.2.23-15

BTW: SELinux still prevents hcid to access DBUS (see also bug #183145):

Mar 10 19:20:45 baraddur hcid[11444]: Bluetooth HCI daemon
Mar 10 19:20:45 baraddur hcid[11444]: Can't get system message bus name:
Connection ":1.12" is not allowed to own the service "org.bluez" due to SELinux
policy
Mar 10 19:20:45 baraddur hcid[11444]: Unable to get on D-BUS

Testing under "setenforce 0":

Mar 10 19:25:34 baraddur hcid[11571]: pin_code_request (sba=00:0A:3A:58:BC:54,
dba=00:02:EE:93:9F:C8)
Mar 10 19:25:34 baraddur hcid[11571]: org.bluez.Error.WrongArgs: Byte array
expected, other type given

$ bluez-pin --dbus
11605: arguments to dbus_message_iter_get_fixed_array() were incorrect,
assertion "(subtype == DBUS_TYPE_INVALID) || dbus_type_is_fixed (subtype)"
failed in file dbus-message.c line 1743.
This is normally a bug in some application using the D-BUS library.
Comment 21 Stefan Becker 2006-03-15 10:00:38 EST
With the latest bluez-pin it finally works (as long as you use "setenforce 0")...

dbus-0.61-3
bluez-libs-2.25-1
bluez-pin-0.30-2
bluez-utils-2.25-4
Comment 22 John (J5) Palmieri 2006-03-15 10:38:24 EST
In which case this should be changed to an SELinux issue.  We strive to have all
software work with SELinux.  Stefan, can you attach the relevant portions of
/var/log/audit/audit.log.  Thanks.
Comment 23 Stefan Becker 2006-03-15 10:46:20 EST
There is already bug #183145 open for this, so I think this one can be closed...
Comment 24 John (J5) Palmieri 2006-03-15 10:55:22 EST

*** This bug has been marked as a duplicate of 183145 ***

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