Ken Giusti created PROTON-2775:
----------------------------------
Summary: pn_buffer_ensure crash due to overflow
Key: PROTON-2775
URL: https://issues.apache.org/jira/browse/PROTON-2775
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.40.0
Reporter: Ken Giusti
pn_buffer_ensure(pn_buffer_t *buf, size_t size) will expand the capacity of
_buf_ to hold at least {_}size{_}.
The implementation of pn_buffer_t maintains a capacity field that represents
the size of of the allocated memory buffer. This capacity is implemented as a
uint32_t type.
The issue is that pn_buffer_ensure does not check for buffer wrap within the
uint32_t range, which allows pn_buffer_ensure to wrap the reallocation. This
can result in memory overflow and a crash.
Note well that I don't think having a 2^32-1 maximum limit for a pn_buffer_t is
wrong. I totally agree that even that size is probably overkill.
However I think the problem is that an application can trigger the wrap since
there is no visibility to current capacity value with the current proton API.
E.g. aggressively call pn_link_send() when the output network connection is
blocked by a stalled receiver.
At a minimum proton should detect an overflow event and not blindly double the
capacity if the requested size is within the 32 bit range.
I would also propose that pn_buffer_ensure() invoke abort() if it is passed a
size > UINT32_MAX. This would at minimum prevent a potential buffer overflow
attack and at best alert the application developer that their code is buggy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
