bitlbee with plugin-otr crashes when messaging offline contacts more than once

[anonymous]

Whenever trying to message an offline person, the second message triggers a segfault. On top of that, the plugin doesn't seem to respect otr_policy variable, as I'm getting similar behavior when set to "manual" or "never".

Backtrace here: ​http://codepad.org/kbHqpAwn

[dx]

I can reproduce this.

Shouldn't have priority "blocker" though.

the plugin doesn't seem to respect otr_policy variable

This actually means "the crash happens regardless of otr_policy". The crash happens anyway because all messages are filtered through OTR.

[dx]

I can also reproduce it with an online contact with no previously existing OTR context.

Alice talks to bob, bob doesn't reply, alice talks again = alice's bitlbee crashes.

Alice talks to bob, bob replies, OTR context is created, alice can talk, communication continues normally.

Seems like otrl_context_find() finds a context with matching username, then calls otrl_context_find_recent_instance() which does:

// context.c:174
m_context = context->m_context;
// context.c:180
return m_context->recent_child;

(line numbers from libotr 4.0.0 stable release)

m_context amd context have the same address. (is this normal?). There are proper null checks for both context and m_context

recent_child is NULL.

otrl_message_sending() gets that and dereferences that null at message.c:243

// message.c:243
if (!context->our_instance) {

There are lots of points where NULL is returned by otrl_context_find(), so not checking for that here seems unwise.

The null dereference might be their fault, but what I still don't get is how we're getting the contexts in this state. I barely understand what contexts and instances are. If you're around, pesco, enlighten me.

[anonymous]

I can reproduce this, too. Also, the backtrack is the same. (And IMO it's a showstopper/blocker, when You tend to chat otr/non_otr through the same Bitlbee instance.)

[Flexo <bitlbee@…>]

This patch fixes the eaten messages when otr isn't active (for whatever reason) but doesn't fix the double-message segfault.

I don't have an end-to-end OTR setup at the moment so I haven't been able to test with OTR active, and I've run out of time for today.

I would also like to hear from the original author whether why OTRL_FRAGMENT_SEND_ALL was chosen rather than OTRL_FRAGMENT_SEND_SKIP, which I have changed it to, in case there are subtle effects I haven't noticed.

[Flexo <bitlbee@…>]

Fix for eaten messages when OTR is inactive.

[Flexo <bitlbee@…>]

Uh, disregard last remark, was intended for #1109

[anonymous]

Just wanted to report: the code was merged, but for some reason there is no up-to-date build of the otr-plugin. The version of all packages has increased to 1006 except for the otr-plugin. Dunno if this happened on purpose.

[wilmer]

I've disabled those builds for now due to bugs plus me needing to figure out which Debian/Ubuntu versions it can actually build for (thanks to libotr not giving a damn about bw compatibility).

[dx]

Just to be clear: Flexo's patch is NOT for this bug. BitlBee still crashes.

Also, it's not just for offline contacts. All people with no previous otr context are affected.

[pesco]

This is a null-pointer dereference bug in libotr 4.0.0 that is triggered by using OTRL_INSTAG_RECENT. When a new OTR context is created via the add_context part in otrl_message_sending, the recent_child field is not set. On the next message otrl_message_sending crashes because even though there is a context, otrl_context_find returns NULL.

A workaround is to use OTRL_INSTAG_BEST which does not use the recent_child field.

So implemented with r1008 of ​http://code.khjk.org/bitlbee/.

[anonymous]

Big thanks to You pesco, I can confirm that revision 1008 from Your repo resolves this issue!

[dx]

Wilmer just merged r1007 in the main branch (includes r1007 and r1008 of pesco's branch). Thanks pesco!