Menu
▾
▴
#49 Zero length messages cause evmsd to take a segfault
EVMS on Linux uses heartbeat's cluster plumbing base64
functions to encode and decode binary data for sending
over the wire. A zero-length message, like one passed
for EVMS_CLOSE_ENGINE, gets encoded as a single 't'
character.
Because base64 encoding must be a multiple of 4 in
length, the base64_to_binary() call on the remote end
fails and returns -1, which gets promptly stored as the
unsigned message length. A subsequent call to
log_message() then causes a segmentation violation
when it tries to read the entire length of virtual memory
from 0 - 0xffffffff.
There are many other zero-length messages generated
by engine/remote.c. I assume they would all fail in the
same manner.
Logged In: YES
user_id=209030
I need a little help understanding the problem. I don't see
how an empty message gets translate into a "t" as bas64 output.
In the EVMS HA plug-in, the call to binary_to_base64() in
frag_send_msg() (plugins/ha/ecefrag.c:247) for a NULL
message should result in binary_to_base64(NULL, 0,
[ptr-to-output-buffer], 1);
Looking at binary_to_base64() in
heartbeat-1.2.0/lib/clplumbing/base64.c:28 it will handle a
0 for the number of input bytes, skipping over the loop for
translating bytes. It will then stick an EOS in the first
position of the output buffer, resulting in the ouput buffer
containing an empty string, not a "t".
Do you have more details on how the output buffer for an
empty message gets encoded as a "t"? I can't see it in the
code. I don't get the segfault that you describe on my test
machines, so I can't reproduce the problem.