Modify

#1110 closed defect (fixed)

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

Reported by: anonymous Owned by: pesco
Priority: blocker Milestone:
Component: OTR Version: devel
Keywords: Cc:
IRC client+version: weechat 0.3.8 & 0.4.2 Operating System: Linux
OS version/distro: debian wheezy 7.2 with libotr5 from wheezy-backports

Description

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

Attachments (1)

patch1.diff (1.1 KB) - added by Flexo <bitlbee@…> at 2014-01-17T21:11:14Z.
Fix for eaten messages when OTR is inactive.

Download all attachments as: .zip

Change History (12)

comment:1 Changed at 2014-01-11T06:43:05Z by 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.

comment:2 Changed at 2014-01-11T11:15:46Z by 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.

comment:3 Changed at 2014-01-17T17:10:27Z by 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.)

comment:4 Changed at 2014-01-17T21:10:33Z by 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.

Changed at 2014-01-17T21:11:14Z by Flexo <bitlbee@…>

Attachment: patch1.diff added

Fix for eaten messages when OTR is inactive.

comment:5 Changed at 2014-01-17T21:13:20Z by Flexo <bitlbee@…>

Uh, disregard last remark, was intended for #1109

comment:6 Changed at 2014-01-28T12:04:16Z by 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.

comment:7 Changed at 2014-01-28T13:15:53Z by 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).

comment:8 Changed at 2014-01-28T16:08:50Z by 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.

comment:9 Changed at 2014-02-02T00:43:12Z by 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/.

comment:10 Changed at 2014-02-06T21:14:19Z by anonymous

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

comment:11 Changed at 2014-02-06T23:08:57Z by dx

Resolution: fixed
Status: newclosed

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

Modify Ticket

Action
as closed The owner will remain pesco.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.