Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
Apple only allows 32 bit unsigned values for UID nodes. Also the encoding
of the length is different from the encoding used for other node types.
The nibble used to mark the size is 1 less than the actual size of the integer
value data, so 0 means 1 byte length 1 means 2 bytes length, etc.
|
|
|
|
|
|
'ref_size'
|
|
|
|
|
|
The uint24_from_be function used memcpy and a call to byte_convert.
Instead the macro now shifts the data appropriately with a new beNtoh
macro that eventually uses be64toh.
This commit also fixes the problem where binary plist data with other
non-power-of-2 sizes (like 5,6, or 7) where not handled correctly,
and actually supports sizes larger than 8 bytes though only the last
8 bytes are actually converted (nobody will come up with such a large
plist anyway).
|
|
As reported in #86, the binary plist parser would force the type of the
key node to be of type PLIST_KEY while the node might be of a different
i.e. non-string type. A following plist_free() might then call free() on
an invalid pointer; e.g. if the node is of type integer, its value would
be considered a pointer, and free() would cause an error.
We prevent this issue by disallowing non-string key nodes during parsing.
|
|
parse_bin_node
|
|
|
|
|
|
plist_from_bin() fails
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.
|
|
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.
|
|
the offset table
|
|
bounds checking
|
|
bounds checking
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
freed memory
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.
|
|
The parsing logic for binary dictionaries wrongly enforced the key type even
on nodes that were already parsed as value nodes. This caused the resulting
plist_t node tree to have key nodes instead of value nodes within dictionaries
for some valid binary plists. This commit should also generally fixes parsing
of binary plist files which use an efficient dictionary reference table.
|
|
|
|
|
|
binary plist
|
|
|
|
mismatch
|
|
|
|
|
|
|
|
|
|
Handle UTF-16 surrogate pair conversion to/from UTF-8
|
|
endianness detection
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- endianness issues: on big endian machines, writing out only part
of an integer was broken (get_needed_bytes(x) < sizeof(x))
-> shift integer before memcpy() on big endian machines
- alignment issues: unaligned reads when loading binary plist. Leads
to slow runtime performance (kernel trapping and fixing things up),
SIGBUS (kernel not helping us out)
-> introduce get_unaligned() and have the compiler generate the code
needed for the unaligned access
(note that there remains unaligned accesses that I haven't been able
to track down - I've seen 2 of them with test #2)
- type-punning issues: breaking strict aliasing rules can lead to
unexpected results as the compiler takes full advantage of the aliasing
while optimizing
-> introduce the plist_uint_ptr union instead of casting pointers
Tested on amd64, alpha and hppa.
|
|
* on armel system floating poing data can have different endianess than
rest of types; hence we fix arm endianess for defined(__VFP_FP__) to
be big/native; this also applies for data parsing/writing
* date parsing didnt flip the endianess back for little endian systems
when reading the values causing test failures; we fix this by ensuring
float endianess is applied when parsing
|
|
|
|
|
|
|
|
|