[Pkg-gtkpod-devel] Bug#745844: Segfault in libimobiledevice applications also due to poor error-checking.

[Klee Dienes]

I ran into this problem as well, using:

iU  libimobiledevice-dev 
1.1.6+dfsg-3                                   amd64        Library 
for communicating with iPhone and iPod Touch devices
iU  libimobiledevice-doc 
1.1.6+dfsg-3                                   all          Library 
for communicating with iPhone and iPod Touch devices
iU  libimobiledevice-utils 
1.1.6+dfsg-3                                   amd64        Library 
for communicating with iPhone and iPod Touch devices
iU  libimobiledevice4:amd64 
1.1.6+dfsg-3                                   amd64        Library 
for communicating with the iPhone and iPod Touch
iU  libimobiledevice4-dbg:amd64 
1.1.6+dfsg-3                                   amd64        Library 
for communicating with iPhone and iPod Touch devices
iU  python-imobiledevice 
1.1.6+dfsg-3                                   amd64        Library 
for communicating with iPhone and iPod Touch devices
ii  libusbmuxd-dev:amd64 
1.0.9-1                                        amd64        USB 
multiplexor daemon for iPhone and iPod Touch devices - devel
ii  libusbmuxd2:amd64 1.0.9-1                                        
amd64        USB multiplexor daemon for iPhone and iPod Touch 
devices - library
ii  libusbmuxd2-dbg 1.0.9-1                                        
amd64        USB multiplexor daemon for iPhone and iPod Touch 
devices - debug
ii  usbmuxd 1.0.8-5                                        
amd64        USB multiplexor daemon for iPhone and iPod Touch devices

Assuming the problem is fixed with usbmuxd 1.0.9, it may be worth 
forwarding the bug report in terms of how they handle the response 
from usbmuxd_read_buid().

Both userpref_read_system_buid and pair_record_generate assume that 
usbmuxd_read_buid() will return a valid string and do no checking of 
the return value.

userpref_read_system_buid will try to debug_info the returned 
string, which would likely crash ... but it's a moot point since as 
far as I can tell libimobiledevice is building with STRIP_DEBUG_CODE.

I'm happy to submit a patch, or alternately a bug report directly to 
the libimobiledevice folks, or a separate bug here ... but figured 
I'd check here first to see your preference.


(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/idevicename
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 2, pair_record_generate (pair_record=0x7fffffffdff0, 
client=0x653130) at lockdown.c:878
878             userpref_read_system_buid(&system_buid);
(gdb) step
userpref_read_system_buid 
(system_buid=system_buid at entry=0x7fffffffe000) at userpref.c:184
184             int res = usbmuxd_read_buid(system_buid);
(gdb) next
0x00007ffff79b9cb0 in usbmuxd_read_buid at plt () from 
/usr/lib/x86_64-linux-gnu/libimobiledevice.so.4
(gdb) fin
Run till exit from #0  0x00007ffff79b9cb0 in usbmuxd_read_buid at plt ()
    from /usr/lib/x86_64-linux-gnu/libimobiledevice.so.4
pair_record_generate (pair_record=0x7fffffffdff0, client=0x653130) 
at lockdown.c:879
879             plist_dict_set_item(*pair_record, 
USERPREF_SYSTEM_BUID_KEY, plist_new_string(system_buid));
(gdb) print system_buid
$2 = 0x0
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106     ../sysdeps/x86_64/strlen.S: No such file or directory.