Crasher during remote initiated pairing
Heya,
I have a particularly stubborn device, the TomTom Go Remote that tries to connect to my computer as soon as it's turned on, even when I've removed the pairing on the computer side.
With GNOME's Bluetooth wizard open, I receive an out of the blue request for pairing, I pass it the expected PIN code (0000), I then find that the wizard doesn't work as I expected and turn it off. bluetoothd promptly crashes:
Program received signal SIGSEGV, Segmentation fault.0x00007f0cf9ffde24 in agent_auth_cb (agent=<optimized out>, derr=0x7fffab655920, user_data=0x7f0cfb2e0020) at src/adapter.c:4370
4370 struct service_auth *auth = adapter->auths->head->data;
(gdb) p adapter
$1 = (struct btd_adapter *) 0x7f0cfb2e0020
(gdb) p adapter->auths
$2 = (GQueue *) 0x7f0cfb2d1240
(gdb) p adapter->auths->head
$3 = 0x0
Some missing NULL checks?
I imagine that this should be reproduceable using simple-agent and making it exit after replying to RequestPinCode.
This happens with 5.10 and 5.11:
https://retrace.fedoraproject.org/faf/problems/1353319/
Cheers
Hi Bastien,
Quoted 21 lines · Bastien Nocera
Heya,
I have a particularly stubborn device, the TomTom Go Remote that tries to connect to my computer as soon as it's turned on, even when I've removed the pairing on the computer side.
With GNOME's Bluetooth wizard open, I receive an out of the blue request for pairing, I pass it the expected PIN code (0000), I then find that the wizard doesn't work as I expected and turn it off. bluetoothd promptly crashes:
Program received signal SIGSEGV, Segmentation fault.
0x00007f0cf9ffde24inagent_auth_cb(agent=<optimized out>, derr=0x7fffab655920, user_data=0x7f0cfb2e0020) atsrc/adapter.c:4370
4370 structservice_auth*auth =adapter->auths->head->data;
(gdb) p adapter
$1 = (structbtd_adapter*)0x7f0cfb2e0020
(gdb) padapter->auths
$2 = (GQueue *)0x7f0cfb2d1240
(gdb) padapter->auths->head
$3 =0x0
Quoted 1 line
Some missing NULL checks?
Not sure. The GQueue internals should not be of our concern, meaning if we have a non-NULL GQueue pointer I'd expect it to be safe to call g_queue_is_empty on that pointer. I wonder if this is some kind of freed memory access or similar. valgrind might show this.
Johan
Hi Bastien,
Quoted 22 lines · Johan Hedberg
Quoted 21 lines · Bastien Nocera
Heya,
I have a particularly stubborn device, the TomTom Go Remote that tries to connect to my computer as soon as it's turned on, even when I've removed the pairing on the computer side.
With GNOME's Bluetooth wizard open, I receive an out of the blue request for pairing, I pass it the expected PIN code (0000), I then find that the wizard doesn't work as I expected and turn it off. bluetoothd promptly crashes:
Program received signal SIGSEGV, Segmentation fault.
0x00007f0cf9ffde24inagent_auth_cb(agent=<optimized out>, derr=0x7fffab655920, user_data=0x7f0cfb2e0020) atsrc/adapter.c:4370
4370 structservice_auth*auth =adapter->auths->head->data;
(gdb) p adapter
$1 = (structbtd_adapter*)0x7f0cfb2e0020
(gdb) padapter->auths
$2 = (GQueue *)0x7f0cfb2d1240
(gdb) padapter->auths->head
$3 =0x0
Quoted 6 lines
Quoted 1 line
Some missing NULL checks?
Not sure. The GQueue internals should not be of our concern, meaning if we have a non-NULL GQueue pointer I'd expect it to be safe to call
g_queue_is_emptyon that pointer. I wonder if this is some kind of freed memory access or similar. valgrind might show this.
Just ignore the above, I was following the exact line number in the trace (4370) which landed me in process_auth_queue() instead of agent_auth_cb(), i.e. I was looking at the wrong piece of code and making the wrong conclusions.
Johan
Hi Bastien,
Quoted 19 lines · Bastien Nocera
I have a particularly stubborn device, the TomTom Go Remote that tries to connect to my computer as soon as it's turned on, even when I've removed the pairing on the computer side.
With GNOME's Bluetooth wizard open, I receive an out of the blue request for pairing, I pass it the expected PIN code (0000), I then find that the wizard doesn't work as I expected and turn it off. bluetoothd promptly crashes:
Program received signal SIGSEGV, Segmentation fault.
0x00007f0cf9ffde24inagent_auth_cb(agent=<optimized out>, derr=0x7fffab655920, user_data=0x7f0cfb2e0020) atsrc/adapter.c:4370
4370 structservice_auth*auth =adapter->auths->head->data;
(gdb) p adapter
$1 = (structbtd_adapter*)0x7f0cfb2e0020
(gdb) padapter->auths
$2 = (GQueue *)0x7f0cfb2d1240
(gdb) padapter->auths->head
$3 =0x0
Quoted 4 lines
Some missing NULL checks?
I imagine that this should be reproduceable using simple-agent and making it exit after replying to RequestPinCode.
The agent_auth_cb is actually not used for pairing but for authorization, so whether it's RequestPinCode or RequestPasskey wont matter for the above backtrace. Anyway, I was never able to reproduce the exact same issue as you had, but I did find two places needing some extra checks (one in adapter.c and another in agent.c). So it'd be good if you could give the latest git a spin and see if you can still reproduce the crash.
Johan
On Wed, 2013-11-27 at 11:06 +0200, Johan Hedberg wrote:
<snip>
Quoted 7 lines
The
agent_auth_cbis actually not used for pairing but for authorization, so whether it's RequestPinCode or RequestPasskey wont matter for the above backtrace. Anyway, I was never able to reproduce the exact same issue as you had, but I did find two places needing some extra checks (one inadapter.cand another inagent.c). So it'd be good if you could give the latest git a spin and see if you can still reproduce the crash.
That seems to work fine, thanks.