[jacorb-bugs] [Bug 958] New: BufferManager gives bad buffers

bugzilla-daemon at jacorb.org bugzilla-daemon at jacorb.org
Mon Jul 15 23:38:14 CEST 2013


http://www.jacorb.org/bugzilla/show_bug.cgi?id=958

            Bug ID: 958
           Summary: BufferManager gives bad buffers
           Product: JacORB
           Version: 3.3
          Hardware: PC
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: ORB
          Assignee: jacorb-bugs at lists.spline.inf.fu-berlin.de
          Reporter: mesnier_p at ociweb.com

Created attachment 419
  --> http://www.jacorb.org/bugzilla/attachment.cgi?id=419&action=edit
Buffer manager diff

The application was choking when a stream became corrupt, forcing socket
closure and loss of message. The stream was corrupted because a previous read
request had a buffer too small for desired read. That previous read had pulled
the GIOP message header and determined the message length which was between
2^18 and 2^19 bytes. The reader went to the buffer manager, which correctly
determined a buffer from slot 18 was needed, and slot 18 had an available
buffer. Unfortunately the actual size of that buffer was 0x5A000 rather than
the expected 0x7FFFF, and thus insufficient for the necessary read.

The problem is that somehow a buffer was offered to the buffer manager that
stored it in the appropriate slot, but without checking that the actual size of
the returned buffer actually met the criteria for that slot.

The source of the bad buffer was the CDROutputStream class. In this case, the
user had obtained one from the ORB, then used setBuffer() to supply a buffer
into which the data was marshaled but then when done, the buffer was returned
to the buffer manager.

The solution is 2 fold. First, the buffer manager should validate the size of
returned buffers. Second, the CDROutputStream should have a sense of buffer
ownership.

Addressing the buffer manager is straight forward. The CDROuputStream's buffer
ownership is a little trickier. I think the easiest solution would be to add an
overloaded setBuffer method that takes an explicit ownership flag indicating
that the stream can return the buffer to the manager or not. The existing 1-arg
call would be the same as the 2-arg call with the second argument true:

The only risk is that if the externally set buffer were insufficient for the
data being marshaled, the check() method would grow the buffer discarding the
original.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-bugs/attachments/20130715/f1e59df1/attachment-0001.html>


More information about the jacorb-bugs mailing list