Make sure to increment the parcel data position even when trying to
improperly read from protected data
Bug: 29833520
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtection
Test (M): cts-tradefed run cts -c android.os.cts.ParcelTest -m testBinderDataProtectionIncrements
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtection
Test: cts-tradefed run cts -m CtsOsTestCases -t android.os.cts.ParcelTest#testBinderDataProtectionIncrements
Change-Id: Ie4aae6277fc5f5c924f603d9828c3a608998b986
Merged-In: Ie4aae6277fc5f5c924f603d9828c3a608998b986
(cherry picked from commit 6a825e8ad1a3928dd872bb7c3fbcd94784d77267)
The check added to each non-object reads adds an overhead. If the
objects (binders and file descriptors) were written to the Parcel in
sequential order then check adds a small O(1) overhead to each read,
plus an O(N) overhead to the first read (to verify the N objects were
added in order).
If the objects were written out of order (as in by jumping around the
Parcel
with setDataPosition and writing Binder, DON'T DO THIS!!) (writing non
objects out of order is fine), the first read is forced to sort the
objects
in the internal bookkeeping. Based on the assumption non sequential
writes
are infrequent and overall Parcels are probably mostly sorted, insertion
sort was used. Worst case sorts will add an O(N^2) overhead to the first
non object read from the Parcel.
Test: run cts -m CtsOsTestCases -t android.os.cts.ParcelTest
Bug: 29833520
Change-Id: I82de8eb5f5eb56f869542d5358e96884c24301b2
(cherry picked from commit c517681c66a1a387be657e0cf06da8d19659dd14)
writeInplace() itself already pads securely, by masking off
the padded bytes. If the padding is done before calling
writeInplace(), no mask is applied, and heap data can leak.
Bug: 77237570
Test: builds
Change-Id: Ide27a0002d4ed4196530430760245b971f6a3f44
Merged-In: Ide27a0002d4ed4196530430760245b971f6a3f44
(cherry picked from commit f8542381b72a7bb2452a5278a00ca8c34edbf8a0)
(cherry picked from commit 732132b765cd7b667f16cf32f0fe4c852d7d44dd)
Change-Id: Id65e4573e18ab68b804f1cf63a6977a71da01e5d
check if device matches the ashmem rdev, before calling
ashmem_get_size_region. This eliminates making this call
when associated with other driver file descriptors.
Bug: 26374183
Bug: 26918423
Bug: 26871259
Change-Id: I1f88c2c93ea35a73c8e14125f3d1a6c67fa4f15b
check if device is a character device, before calling
ashmem_get_size_region. We do not check if the st_rdev
matches /dev/ashmem. So this at least eliminates making
this call when associated with a socket.
Bug: 26374183
Change-Id: I68ed9d1c2cd4c47228ed065e3e18eb4151f038f4
The addition of ashmem size tracking can lead to parcel objects
overwriting other values on the stack in old binary blobs.
Change-Id: Ife8514be1ba639c4061de38b59794c46bcc2d7f8
Makes sure we don't change the memory layout of the Parcel class
to maintain binary compatibility with prebuilts linking against
libbinder.
Bug: 25004154
Change-Id: I656687497f08bb85cefda796aafa2341e601e30a
writeByteArray writes the size using sizeof(size_t), however it is always
read using readInt32(). On devices where sizeof(size_t) != 4 this causes
extra bytes to be written.
BUG: 22204736
Change-Id: I8d4507b6b616857ef5827f1fe9da0907d09abf0e
Make sure that we don't go haywire if an exponential buffer growth
operation winds up wrapping integer range. Along the way, fix a
bookkeeping bug in BufferedTextOutput that would cause it to keep
spuriously realloc()ing on every append().
Bug 20674694
Change-Id: Ia845b7de36b90672a151a918ffc26c7da68e20a2
We now check for fd-legality before committing binder objects to
the flattened data buffer rather than after. Previously we would
wind up corrupting the parcel and incurring driver-level errors,
as well as potentially leaking FDs.
Bug 21428802
Change-Id: Ice0d641b3dcc41fb1b8c68ce2e2ebd744c2863a1
Add functions to allow a client to take over the ashmem region
that was transferred so that it can claim it for its own and
reuse it.
Add support for mutable ashmem regions too.
Bug: 21428802
Change-Id: I16eca338cdb99b07d81fc43573d53ce86dbc60c8
Attempts to replicate Java parceling in native code is fraught with
peril.
Change-Id: I4359036c5dddd1b886d886beef1d060523e53e5f
(cherry picked from commit f47a381001)
When appending one parcel's contents to another, ignore binder
objects within the source Parcel that appear to lie beyond the
formal bounds of that Parcel's data buffer.
Bug 17312693
Change-Id: If592a260f3fcd9a56fc160e7feb2c8b44c73f514
The inputs to native_handle_create can cause an overflowed allocation,
so check the return value of native_handle_create before accessing
the memory it returns.
Bug:19334482
Change-Id: I1f489382776c2a1390793a79dc27ea17baa9b2a2
It's a security best practice for size_t values to be rejected if
they are greater than INT32_SIZE. This is intended to prevent the
common error of inadvertently passing a negative int value to a
function, which after conversion to an unsigned type, becomes a huge
number, defeating the purpose of bounds checking.
This patch also addresses a bug where the call to:
Parcel::write(buf, (size_t) -1);
would call writeInPlace() which uses PAD_SIZE on the supplied
argument. This would then cause an integer overflow, with PAD_SIZE
returning a small value, but the memcpy in Parcel::write using the
old large length value.
Bug: 19573085
Change-Id: Ib11bfb3dae4f3be91cd17b2c676926700972c7b8
Adds readUint32 and writeUint32 methods to the Parcel class. This
saves a lot of static_casting in anything implementing a Binder
interface on the native side.
Change-Id: Iafc73b0633654a3a4c49767f41806b56906c924f
* Explicit conversion for atomic_uintptr_t initialization.
* Fix string literal concatenation to not be a UD literal.
* Use __typeof__ instead of typeof (should become decltype once this
actually moves to C++11).
Bug: 18466763
Change-Id: I4eedddfb945a2a703ed27317cb6e2b3041b1ebfc
...in Parcel destructor
Don't use a Mutux object, just use simple posix mutex primitives,
to avoid static init/destroy order problems.
Change-Id: Ic012d94297564c0a55d58869f8276d7d10545fbc
mmap returns MAP_FAILED (which is -1) and not NULL on
failure.
Diagnosed by cferris.
bug: 17909809
Change-Id: I609788ebf94742ef88af002d2d3f3bc9b9e520ac
Temporary extra debug validation for b/17477219: a Parcel recipient is
getting a positive but invalid fd unexpectedly. Trying to track down
where it's coming from.
Debug code for bug: 17477219
Change-Id: Idb1e71621025a3928c7adc88fd44790e1abd2a01
All uses of this API have been removed. It should
never have been made public in the first place.
bug: 15424960
Change-Id: Id07d24ec95b2b393e6da138a7e8a9a4ecebeca94
It can help to detect some kind of error, such as why GraphicBuffer::flatten
will crash when handle is null.
Change-Id: I703cd035b96edb7afb324cf24d8230d4e55f4f52
Signed-off-by: Jun Jiang <jun.a.jiang@intel.com>
Michael Wachenschwanz