Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
|
|
integer)
Credit to Wang Junjie <zhunkibatu@gmail.com> (#90)
Credit to OSS-Fuzz
|
|
|
|
Credit to OSS-Fuzz
|
|
Credit to OSS-Fuzz
|
|
Credit to Wang Junjie <zhunkibatu@gmail.com> (#93)
|
|
|
|
|
|
after strncpy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit adds proper debug/error messages being printed if the binary
plist parser encounters anything abnormal. To enable debug logging,
libplist must be configured with --enable-debug, and the environment
variable PLIST_BIN_DEBUG must be set to "1".
|
|
|
|
|
|
|
|
Issue #92 pointed out an problem with (invalid) bplist files which have
exactly one structured node whose subnode reference itself.
The recursion check used a fixed size array with the size of the total number
of objects. In this case the number of objects is 1 but the recursion check
code wanted to set the node_index for the level 1 which leads to an OOB write
on the heap. This commit fixes/improves two things:
1) Prevent OOB write by using a dynamic data storage for the used node
indexes (plist_t of type PLIST_ARRAY)
2) Reduces the memory usage of large binary plists, because not the total
number of nodes in the binary plist, but the number of recursion levels
is important for the recursion check.
|
|
As reported in #91, the code that will read the big endian integer value
of variable size did not check if the actual number of bytes is still
withing the range of the actual plist data.
This commit fixes the issue with proper bounds checking.
|
|
|
|
bounds checking
|
|
node sizes > 14
The sizes where effectively parsed by calling parse_uint_node() which
allocates a node_t (along with plist_data_t) that is immediately freed
after retrieving the integer value it holds.
This commit changes the code to directly operate on the binary stream
to 'just' read the size instead, reducing the memory footprint further.
|
|
|
|
|