Will Thompson (will.thompson.uk) reports:

Calculating a XEP-0115 hash involves sorting the fields of data forms in the 
contact's capabilities according to their field name. 
wocky_caps_hash_compute_from_lists() does this using this function:

  gint
  wocky_data_form_field_cmp (const WockyDataFormField *left,
      const WockyDataFormField *right)
  {
    return strcmp (left->var, right->var);
  }

This will obviously crash if either ->var is NULL, but WockyDataForm validates 
forms it parses so this shouldn't happen, right? Unfortunately, 
http://xmpp.org/extensions/xep-0004.html#protocol-field says:

> If the <field/> element type is anything other than "fixed" (see below), it
> MUST possess a 'var' attribute that uniquely identifies the field in the 
> context of the form (if it is "fixed", it MAY possess a 'var' attribute).

And WockyDataForm implements this correctly:

  var = wocky_node_get_attribute (node, "var");
  if (var == NULL && type != WOCKY_DATA_FORM_FIELD_TYPE_FIXED)
    {
      DEBUG ("field node doesn't have a 'var' attribute; ignoring");
      return FALSE;
    }

So we have a remotely-triggered DoS: send Gabble a <presence> with a caps hash;
include a form with an anonymous fixed field in the reply; boom. Since anyone 
can send presence to anyone else, and Gabble always looks up any caps it sees 
in any presences it receives. (Note that this is a presence leak, too; another 
bug, I think.)

I have some fixes; patches to follow. I will also suggest that 
http://xmpp.org/extensions/xep-0115.html be updated to mention this.

External references:

https://bugs.freedesktop.org/show_bug.cgi?id=61433
http://lists.freedesktop.org/archives/telepathy-bugs/2013-February/021155.html
http://xmpp.org/extensions/xep-0115.html