Project

General

Profile

Bug #4674

messenger: crash in read_partial_message()

Added by Alex Elder almost 11 years ago. Updated almost 11 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Testing with 3.8.0-ceph-00293-ga39ffbd (which is a test
version of some code I've posted for review) I hit a
crash in read_partial_message(). It appears to have occurred
while dereferencing con->in_msg in this line of code:

ret = ceph_con_in_msg_alloc(con, &skip);
if (ret < 0)
return ret;
if (data_len > con->in_msg->data_length) {      <=========
pr_warning("%s skipping long message (%u > %zd)\n",
func, data_len, con->in_msg->data_length);
skip = 1;
}

This means that ceph_con_in_msg_alloc() returned a non-negative
value yet con->in_msg was a null pointer. (NULL was in fact the
value according to the register dump; the machine is stuck so I
can't use kdb to learn any more.)\

History

#1 Updated by Alex Elder almost 11 years ago

And now that I've looked at it, I see the cause...

It's this commit:

commit 0b809454cd5cd5cf3129a5beb6ba06970fde41a3
Author: Alex Elder <>
Date: Fri Apr 5 14:46:01 2013 -0500

libceph: skip message if too big to receive
We know the length of our message buffers.  If we get a message
that's too long, just dump it and ignore it.
This resolves:
http://tracker.ceph.com/issues/4664
Signed-off-by: Alex Elder &lt;&gt;

If ceph_con_in_msg_alloc() sets the skip flag, it will
not have set con->in_msg and it will return 0.

So if a message is allocated, skip won't be set, and if
skip is set, there will be no message.

So that change (which has not yet been committed) will
need an update to address this.

#2 Updated by Ian Colle almost 11 years ago

  • Project changed from teuthology to rbd

#3 Updated by Alex Elder almost 11 years ago

  • Status changed from In Progress to Rejected

Rejecting this. It was a bug in a patch that had not
yet been committed. I fixed that patch, and it has
now been reviewed and committed. See:
http://tracker.ceph.com/issues/4664

Also available in: Atom PDF