D-Bus daemon endianness issue

[Havoc Pennington]

Hi,

Thanks for the report.

I may see the problem, in 
http://webcvs.freedesktop.org/dbus/dbus/dbus/dbus-marshal-header.c?view=markup 
it appears to me that _dbus_header_byteswap() updates header->byte_order 
but does not reset the byte order in header->data[0]. header->byte_order 
is effectively a cache of header->data[0].

To test this theory, you could try adding 
_dbus_string_set_byte(&header->data, 0, header->byte_order)
at the end of _dbus_header_byteswap and see if it helps. Would be 
appreciated since it would take a while for someone else to set up the 
conditions to reproduce the bug. Though, it would be nice to have a unit 
test covering this.

I have no theory on why this would happen with only methods and not 
signals, though, so that is one reason the above is not a completely 
convincing explanation.

Alp Toker wrote:
> It may be possible not only to crash others' connections to the bus in 
> some configurations, but also to use a carefully crafted sequence of 
> messages to place applications in an unexpected state.

The reference implementation is intended to be robust against broken 
messages (generally it will drop the connection if the other end is 
determined to be sending something mangled). If you encounter a case 
where it gets confused or crashes instead of disconnecting, that would 
certainly be a bug.

So there are two layers of possible bug, one is if the reference 
implementation sends bad messages (some values not in the right 
endianness) and the other is if it breaks or crashes due to bad messages.

Havoc