diff options
author | Jens Gulin <jens.gulin@sonymobile.com> | 2014-03-06 18:15:43 +0100 |
---|---|---|
committer | Elliott Hughes <enh@google.com> | 2014-04-03 11:19:54 -0700 |
commit | d3c8d5b8d4ade074129b65199a8048c81089ee0e (patch) | |
tree | ed11e4123581fdf4b625235a6fc9d5c2729791ff /init | |
parent | 223fc42b5e289e882f67c893374ffbef595a6901 (diff) | |
download | system_core-d3c8d5b8d4ade074129b65199a8048c81089ee0e.zip system_core-d3c8d5b8d4ade074129b65199a8048c81089ee0e.tar.gz system_core-d3c8d5b8d4ade074129b65199a8048c81089ee0e.tar.bz2 |
Handle errno properly to avoid corrupt str_parms
A normal sequence of calls is as follows:
str_parms_create_str, str_parms_add_str, str_parms_destroy.
In some cases the destroy caused double free.
str_parms_add_str will clone the input and send it to hashmapPut
for storage. If hashmapPut did not store the strings it will raise
errno = ENOMEM and leave caller with ownership of the strings.
In any of these cases it will be safe to destroy the str_parms.
But what if it wasn't hashmapPut that said NOMEM? What if there
was a stale NOMEM already before a successful hashmapPut?
In that case the strings will be successfully added to the list
(if new), but when str_parms_add_str sees the NOMEM it will free
them anyway, leaving dangling pointers in the str_parms!!
It is the responsibility of the caller to clear errno before any
interesting call. This patch makes sure that str_parms_add_str
reacts only on errno emmitted from hashmapPut.
Change-Id: If87e4bcc482f09e1c66133d33517b152ebdac65f
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions