Crasher during remote initiated pairing

Crasher during remote initiated pairing

[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.
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

Re: Crasher during remote initiated pairing

[Johan Hedberg]

Hi Bastien,

On Mon, Nov 25, 2013, Bastien Nocera wrote:
> 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?

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

Re: Crasher during remote initiated pairing

[Johan Hedberg]

Hi Bastien,

On Tue, Nov 26, 2013, Johan Hedberg wrote:
> On Mon, Nov 25, 2013, Bastien Nocera wrote:
> > 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?
> 
> 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.

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

Re: Crasher during remote initiated pairing

[Johan Hedberg]

Hi Bastien,

On Mon, Nov 25, 2013, Bastien Nocera wrote:
> 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.

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

Re: Crasher during remote initiated pairing

[Bastien Nocera]

On Wed, 2013-11-27 at 11:06 +0200, Johan Hedberg wrote:
<snip>
> 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.

That seems to work fine, thanks.