[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-2890: -- Labels: easyfix pull-request-available (was: easyfix) > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Assignee: Alexander A. Strelets >Priority: Critical > Labels: easyfix, pull-request-available > Fix For: 3.4.11, 3.5.4, 3.6.0 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-2890: Fix Version/s: (was: 3.4.10) 3.4.11 3.6.0 3.5.4 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-2890: Affects Version/s: 3.6.0 3.5.3 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10, 3.5.3, 3.6.0 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.5.4, 3.6.0, 3.4.11 > > > ZooKeeper C Client *+single thread+* build > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander A. Strelets updated ZOOKEEPER-2890: - Description: ZooKeeper C Client *+single thread+* build Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid address+. The true case: this happens when an active _multi_ request with _create_ sub-request is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. The significant condition is that the _create_ request is not a stand-alone one, but namely a sub-request within the _multi_ request. In this case the _deserialize_response()_ is called recursively (for each sub-request), and when it is called for the _create_ subrequest (from the nested _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so the _if (failed)_ condition branches to the _else_ part. Note that in the stand-alone create-request case this does not occur. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true multi-response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error overall status and empty or insufficient payload). This is a proposed fix: https://github.com/apache/zookeeper/pull/359 was: Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid address+. The true case: this happens when an active _multi_ request with _create_ sub-request is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. The significant condition is that the _create_ request is not a stand-alone one, but namely a sub-request within the _multi_ request. In this case the _deserialize_response()_ is called recursively (for each sub-request), and when it is called for the _create_ subrequest (from the nested _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so the _if (failed)_ condition branches to the _else_ part. Note that in the stand-alone create-request case this does not occur. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true multi-response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error overall status and empty or insufficient payload). This is a proposed fix: https://github.com/apache/zookeeper/pull/359 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical >
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander A. Strelets updated ZOOKEEPER-2890: - Environment: Linux ubuntu 4.4.0-87-generic gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 https://github.com/apache/zookeeper.git branch-3.4 ZooKeeper C Client *+single thread+* build was: Linux ubuntu 4.4.0-87-generic gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 https://github.com/apache/zookeeper.git branch-3.4 > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 > ZooKeeper C Client *+single thread+* build >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.10 > > > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander A. Strelets updated ZOOKEEPER-2890: - Environment: Linux ubuntu 4.4.0-87-generic gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 https://github.com/apache/zookeeper.git branch-3.4 was: Linux ubuntu 4.4.0-87-generic gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 https://github.com/apache/zookeeper.git branch-3.4 ZooKeeper C Client *+single thread+* build > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.10 > > > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The _deserialize_ function, which is called the first, is expected to assign > the _res_ variable with a value from the parsed _struct iarchive *ia_. But, > if _ia_ contains for example insufficient amount of bytes the > _deserialize_String()_ function refuses of assigning a value to _res_, and > _res_ stays uninitialized (the true case is described below). Then, the > _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ > with arguments. If incidentally the memory region in the program stack under > the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid > address+. > The true case: this happens when an active _multi_ request with _create_ > sub-request is completed on call to _zookeeper_close()_ with the so called > "Fake response" which is fabricated by the function _free_completions()_. > Such response includes only the header but +zero bytes for the body+. The > significant condition is that the _create_ request is not a stand-alone one, > but namely a sub-request within the _multi_ request. In this case the > _deserialize_response()_ is called recursively (for each sub-request), and > when it is called for the _create_ subrequest (from the nested > _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so > the _if (failed)_ condition branches to the _else_ part. Note that in the > stand-alone create-request case this does not occur. > *I suspect this may happen not only due to call to _zookeeper_close()_ but on > reception of a true multi-response from the server* containing insufficient > number of bytes (I'm not sure if it can be a proper response from the server > with an error overall status and empty or insufficient payload). > This is a proposed fix: https://github.com/apache/zookeeper/pull/359 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander A. Strelets updated ZOOKEEPER-2890: - Description: Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid address+. The true case: this happens when an active _multi_ request with _create_ sub-request is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. The significant condition is that the _create_ request is not a stand-alone one, but namely a sub-request within the _multi_ request. In this case the _deserialize_response()_ is called recursively (for each sub-request), and when it is called for the _create_ subrequest (from the nested _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so the _if (failed)_ condition branches to the _else_ part. Note that in the stand-alone create-request case this does not occur. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true multi-response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error overall status and empty or insufficient payload). This is a proposed fix: https://github.com/apache/zookeeper/pull/359 was: Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid address+. The true case: this happens when an active _multi_ request with _create_ sub-request is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. The significant condition is that the _create_ request is not a stand-alone one, but namely a sub-request within the _multi_ request. In this case the _deserialize_response()_ is called recursively (for each sub-request), and when it is called for the _create_ subrequest (from the nested _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so the _if (failed)_ condition branches to the _else_ part. Note that in the stand-alone create-request case this does not occur. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true multi-response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error overall status and empty or insufficient payload). > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.10 > > > Function *_deserialize_response()_*, in _case COMPLETION_STRING_,
[jira] [Updated] (ZOOKEEPER-2890) Local automatic variable is left uninitialized and then freed.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander A. Strelets updated ZOOKEEPER-2890: - Description: Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ by invalid address+. The true case: this happens when an active _multi_ request with _create_ sub-request is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. The significant condition is that the _create_ request is not a stand-alone one, but namely a sub-request within the _multi_ request. In this case the _deserialize_response()_ is called recursively (for each sub-request), and when it is called for the _create_ subrequest (from the nested _deserialize_multi()_) the _failed_ parameter is assigned with false (0), so the _if (failed)_ condition branches to the _else_ part. Note that in the stand-alone create-request case this does not occur. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true multi-response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error overall status and empty or insufficient payload). was: Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local automatic variable *_struct CreateResponse res_* which is +left uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and then to _deallocate_GetACLResponse()_. The _deserialize_ function, which is called the first, is expected to assign the _res_ variable with a value from the parsed _struct iarchive *ia_. But, if _ia_ contains for example insufficient amount of bytes the _deserialize_String()_ function refuses of assigning a value to _res_, and _res_ stays uninitialized (the true case is described below). Then, the _deallocate_ function calls _deallocate_String()_ passing uninitialized _res_ with arguments. If incidentally the memory region in the program stack under the _res_ was not equal to NULL, the last call +leads to _free()_ for an invalid address+. The true case: this happens for example when an active _create_ request (or create sub-request within the _multi_ request) is completed on call to _zookeeper_close()_ with the so called "Fake response" which is fabricated by the function _free_completions()_. Such response includes only the header but +zero bytes for the body+. *I suspect this may happen not only due to call to _zookeeper_close()_ but on reception of a true response from the server* containing insufficient number of bytes (I'm not sure if it can be a proper response from the server with an error status and empty payload). Also *I suspect the same case will take place with different requests, but not only the _create_*. Indeed, almost all cases in the _deserialize_response()_ shall be verified as soon as they also use uninitialized _res_-s and _deallocate_ them. Still I have not checked others except the _create_ request with _COMPLETION_STRING_ response. > Local automatic variable is left uninitialized and then freed. > -- > > Key: ZOOKEEPER-2890 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2890 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.10 > Environment: Linux ubuntu 4.4.0-87-generic > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609 > https://github.com/apache/zookeeper.git > branch-3.4 >Reporter: Alexander A. Strelets >Priority: Critical > Labels: easyfix > Fix For: 3.4.10 > > > Function *_deserialize_response()_*, in _case COMPLETION_STRING_, uses local > automatic variable *_struct CreateResponse res_* which is +left > uninitialized+ and passed to the function _deserialize_GetACLResponse()_ and > then to _deallocate_GetACLResponse()_. > The
