Age | Commit message (Collapse) | Author | Files | Lines |
|
string conversion
|
|
|
|
allocated by plist_to_bin()/plist_to_xml()
|
|
|
|
|
|
As mentioned in #142, plist_copy_node() was not correctly handling the hash
tables when cloning array or dict nodes; it incorrectly filled the hash table
with the original child node info, which effectively would lead to a
segmentation fault / UaF if the original array/dict would be freed followed
by an attempt to access an element in the new hash table.
|
|
... and const versions of three member functions, each returning const_iterator:
* Plist::Dictionary::Begin()
* PList::Dictionary::End()
* PList::Dictionary::Find()
|
|
Bug: when creating a new Dictionary object (for example through PList::Node::FromPlist(plist_t node) ), the dictionary_fill function is called from Dictionary() constructor in line 50. It seems that the intended way of calling dictionary_fill() is to pass the _map object by reference, however it is actually passed by value. Thus the changes to the map object made by dictionary_fill() are discarded when the function returns.
Fix: pass _map by reference to keep the changes
|
|
PLIST_DICT
|
|
item of a #PLIST_DICT
|
|
without relying on the index
|
|
be found
|
|
|
|
Also fixes #126 by skipping the strlen() in the assert() if for some reason NULL is returned as data
|
|
|
|
|
|
Similar to #PLIST_DICT, an iterator can now be used for #PLIST_ARRAY
nodes. Get an iterator with plist_array_new_iter() and use
plist_array_next_item() to iterate over the elements.
|
|
overflows
|
|
|
|
directly
As Xiao Deng pointed out in #131, plist_dict_next_item() was very inefficient.
For each iteration, node_nth_child() was called with the iterator value, which
would walk through the child node list on EVERY iteration. If the dictionary
is large this makes things very slow. More than that, after reaching the key
node the code was calling node_nth_child() AGAIN (with iterator value + 1) to
reach the value node, which would walk through the node list once more.
This commit changes the iterator to be a node_t pointer so that the iteration
is done on the node list directly.
|
|
Now that we grow the output buffer enough before writing XML output we can
just write the base64 encoded data directly to the ouput buffer instead of
using a heap buffer that will then be copied to the output buffer.
This makes writing XML output more memory efficient (and slightly faster).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This should only happen due to misuse of the library, e.g. when
calling plist_free() on a node that is a value node in a PLIST_DICT
without properly removing the dictionary entry (key/value pair) and
then calling plist_to_xml() on that dictionary.
|
|
|
|
ASAN reported possible undefined behaviour when writing float/double
values to misaligned addresses.
|
|
These misaligned reads reported by ASAN might lead to undefined behavior.
|
|
Credit to Christophe Fergeau
|
|
|
|
|
|
Clang fails with stricter compilation options, because it thinks safe_year may be uninitialized at the return statement. The logic prevents it from being uninitialized, but probably worth the initialization to avoid the compiler error. The rest of libimobiledevice compiles successfully under the same options.
|
|
This depends on the 'tm' type being declared, which is defined in time.h.
|
|
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|
|
deep-structured plists
Credit to OSS-Fuzz
|
|
Because on 32-bit platforms 32-bit pointers and 64-bit sizes have been
used for the sanity checks of the offset table and object references,
the range checks would fail in certain interger-overflowish situations,
causing heap buffer overflows or other unwanted behavior.
Fixed by wideing the operands in question to 64-bit.
|
|
Credit to OSS-Fuzz
|
|
Instead of letting the buffer grow by just the amount of bytes currently
transformed to base64 - which is basically line by line - we now calculate
the size of the output blob in advance and grow the buffer accordingly.
This will reduce the amount of reallocs to just one, which is especially
important for large data blobs.
While this is a general improvement for all platforms, it is on platforms
like Windows where realloc() can be REALLY slow; converting a 20mb blob to
XML can easily take up to a minute (due to the several hundred thousand
calls to realloc()). With this commit, it will be fast again.
|
|
Passing a size of 0xFFFFFFFFFFFFFFFF to parse_string_node() might result
in a memcpy with a size of -1, leading to undefined behavior.
This commit makes sure that the actual node data (which depends on the size)
is in the range start_of_object..start_of_object+size.
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|