- 10 Nov, 2016 8 commits
-
-
Nikias Bassen authored
When NULL is passed to node_iterator_create() the code tries to access the begin element of the node list and causes a NULL pointer dereference. The value of list is checked a few lines down and iterator->value is then properly assigned in node_iterator_bind().
-
Nikias Bassen authored
Instead of e.g.: if (plist_get_node_type(plist) == PLIST_STRING) you can now write: if (PLIST_IS_STRING(plist))
-
Nikias Bassen authored
-
Nikias Bassen authored
-
Filippo Bigarella authored
If the allocation fails, a lot of bad things can happen so we check the result and return accordingly. We also check that the multiplication used to calculate the buffer size doesn't overflow. Otherwise this could lead to an allocation of a very small buffer compared to what we need, ultimately leading to arbitrary writes later on.
-
Filippo Bigarella authored
offset_table_index is read from the file, so we have full control over it. This means we can point offset_table essentially anywhere we want, which can lead to an out-of-bounds read when it will be used later on.
-
Filippo Bigarella authored
-
Filippo Bigarella authored
-
- 09 Nov, 2016 1 commit
-
-
Filippo Bigarella authored
-
- 31 Oct, 2016 4 commits
-
-
Filippo Bigarella authored
In case parsing inside `node_from_xml` called from line 842 fails, `data` gets freed by the call to `plist_free` at line 899, since `subnode` is actually created by making it point to `data` at line 684. This commit prevents this situation by bailing out whenever parsing in a deeper level of structured nodes fails.
-
Filippo Bigarella authored
If `ctx->pos - p - 1` is greater than `taglen`, we end up writing outside the buffer pointed to by `tag`. This commit fixes it by checking the bounds of the heap buffer before writing.
-
Filippo Bigarella authored
-
Filippo Bigarella authored
-
- 24 Oct, 2016 1 commit
-
-
Nikias Bassen authored
-
- 22 Oct, 2016 1 commit
-
-
Nikias Bassen authored
-
- 19 Sep, 2016 2 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
The main benefit of this is to allow date/time values outside of the 32bit time_t range which is very important on 32bit platforms. But there are also some other issues that will be fixed with this, for example on macOS, mktime() will not work for dates < 1902 despite time_t being 64bit. In the same run this commit will also use a reentrant version of gmtime64_r that should help in multithreaded scenarios. Original code taken from: https://github.com/evalEmpire/y2038
-
- 18 Sep, 2016 1 commit
-
-
Nikias Bassen authored
This removes the timeval union member from the plist_data_t structure. Since struct timeval is 2x64bit on 64bit platforms this member unnecessarily grew the union size to 16 bytes while a size of 8 bytes is sufficient. Also, on 32bit platforms struct timeval is only 2x32bit of size, limiting the range of possible time values. In addition the binary property list format also stores PLIST_DATE nodes as double.
-
- 08 Sep, 2016 1 commit
-
-
Martin Szulecki authored
-
- 29 Jun, 2016 3 commits
-
-
Nikias Bassen authored
In node_to_xml nodes of type PLIST_UID are temporarily converted to a PLIST_DICT for an appropriate XML output. Therefore a PLIST_KEY and a PLIST_UINT node is created and inserted into the PLIST_DICT node. Upon completion, the child nodes of the PLIST_DICT node are detached from the original node and freed, however the data of the child nodes - the key string and the uint value - are not. This commit fixes it.
-
Nikias Bassen authored
Apart from testing the actual integer signed vs. unsigned value storage and conversion, this test will check that the binary plist optimization is not re-using existing values. Basically it will test the fix that was introduced with commit acd226d1.
-
Nikias Bassen authored
Without this check, e.g. the values -1 and 18446744073709551615 would yield in a match, since the comparison will just compare the uint64_t values. However, any value >= 9223372036854775808 and <= 18446744073709551615 is stored as a 128 bit value in binary plist format to make sure it is recognized as an unsigned value. We store it internally as a uint64_t value, but we set the size to 16 vs. 8 accordingly; so this commit will make sure the binary plist optimization will not re-use matching uint64_t values of actually mismatching signed/unsigned values.
-
- 12 May, 2016 4 commits
-
-
Christophe Fergeau authored
Rather than having everyone reimplement binary/XML plist detection by looking at the first bytes of the plist content, it's better to do this detection in libplist and hide that internal detail from library users.
-
Christophe Fergeau authored
It can be useful if one needs to know what type of plist a memory buffer contains.
-
Christophe Fergeau authored
This makes it more convenient to do builds out of the source dir.
-
Nikias Bassen authored
Using a better hashing algorithm and a larger hash table the conversion is A LOT faster when processing large plists. Thanks to Xiao Deng for reporting this issue and suggesting a fix.
-
- 20 Apr, 2016 2 commits
-
-
Frederik Carlier authored
-
- 07 Dec, 2015 1 commit
-
-
Aaron Burghardt authored
Fixes libimobiledevice/libplist#50.
-
- 13 Nov, 2015 1 commit
-
-
Nikias Bassen authored
-
- 05 Feb, 2015 3 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
Nikias Bassen authored
-
- 31 Jan, 2015 2 commits
-
-
Nikias Bassen authored
When parsing binary plists with BPLIST_DICT or BPLIST_ARRAY nodes that are referenced multiple times in a particular file, a buffer was allocated that was not used, and also not freed, thus causing memory leaks.
-
Nikias Bassen authored
Given a specifically ordered binary plist the function plist_from_bin() would free BPLIST_DICT or BPLIST_ARRAY raw node data that is still required for parsing of following nodes. This commit addresses this issues by moving the memory free to the end of the parsing process.
-
- 29 Jan, 2015 2 commits
-
-
Martin Szulecki authored
-
Martin Szulecki authored
-
- 28 Jan, 2015 3 commits
-
-
Nikias Bassen authored
-
Nikias Bassen authored
-
Martin Szulecki authored
-