You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Ken Giusti (Jira)" <ji...@apache.org> on 2023/11/09 15:21:00 UTC

[jira] [Updated] (PROTON-2775) pn_buffer_ensure crash due to overflow

     [ https://issues.apache.org/jira/browse/PROTON-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Giusti updated PROTON-2775:
-------------------------------
    Attachment: proton-2775.txt

> 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
>            Priority: Major
>         Attachments: proton-2775.txt
>
>
> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org