Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
Date: Mon, 13 Mar 2017 16:21:58 +0000 (UTC)
From: "Michael Han (JIRA)" <jira@apache.org>
To: dev@zookeeper.apache.org
Message-ID: <JIRA.12600191.1343237697000.2826.1489422118790@Atlassian.JIRA>
In-Reply-To: <JIRA.12600191.1343237697000@Atlassian.JIRA>
References: <JIRA.12600191.1343237697000@Atlassian.JIRA> <JIRA.12600191.1343237697830@jira-lw-us.apache.org>
Subject: [jira] [Updated] (ZOOKEEPER-1519) Zookeeper Async calls can
 reference free()'d memory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 13 Mar 2017 16:23:04 -0000


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

Michael Han updated ZOOKEEPER-1519:
-----------------------------------
    Fix Version/s:     (was: 3.5.3)
                   3.5.4

> Zookeeper Async calls can reference free()'d memory
> ---------------------------------------------------
>
>                 Key: ZOOKEEPER-1519
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1519
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.3.3, 3.3.6
>         Environment: Ubuntu 11.10, Ubuntu packaged Zookeeper 3.3.3 with some backported fixes.
>            Reporter: Mark Gius
>            Assignee: Daniel Lescohier
>             Fix For: 3.5.4, 3.6.0
>
>         Attachments: zookeeper-1519.patch
>
>
> zoo_acreate() and zoo_aset() take a char * argument for data and prepare a call to zookeeper.  This char * doesn't seem to be duplicated at any point, making it possible that the caller of the asynchronous function might potentially free() the char * argument before the zookeeper library completes its request.  This is unlikely to present a real problem unless the freed memory is re-used before zookeeper consumes it.  I've been unable to reproduce this issue using pure C as a result.
> However, ZKPython is a whole different story.  Consider this snippet:
>   ok = zookeeper.acreate(handle, path, json.dumps(value), 
>                          acl, flags, callback)
>   assert ok == zookeeper.OK
> In this snippet, json.dumps() allocates a string which is passed into the acreate().  When acreate() returns, the zookeeper request has been constructed with a pointer to the string allocated by json.dumps().  Also when acreate() returns, that string is now referenced by 0 things (ZKPython doesn't bump the refcount) and the string is eligible for garbage collection and re-use.  The Zookeeper request now has a pointer to dangerous freed memory.
> I've been seeing odd behavior in our development environments for some time now, where it appeared as though two separate JSON payloads had been joined together.  Python has been allocating a new JSON string in the middle of the old string that an incomplete zookeeper async call had not yet processed.
> I am not sure if this is a behavior that should be documented, or if the C binding implementation needs to be updated to create copies of the data payload provided for aset and acreate.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)