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
Sending transaction to freed BBinder through weak handle
can cause use of a (mostly) freed object. We need to try to
safely promote to a strong reference first.
Change-Id: Ic9c6940fa824980472e94ed2dfeca52a6b0fd342
(cherry picked from commit c11146106f94e07016e8e26e4f8628f9a0c73199)
The addition of ashmem size tracking can lead to parcel objects
overwriting other values on the stack in old binary blobs.
Change-Id: Ife8514be1ba639c4061de38b59794c46bcc2d7f8
The addition of ashmem size tracking can lead to parcel objects
overwriting other values on the stack in old binary blobs.
Change-Id: Ida52cec851a6f9d5a57c8f9130a5875c03dcb094
Using the __attribute__((unused)) preprocessor directive
Change-Id: I29d27fd7eacb962ffa06ccd81ee48b48f3743243
(cherry picked from commit 047c69bb8e17eab6f3432fae200fe94f7e119755)
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
Will be used by the system_server watchdog to monitor the
availability of binder threads in the process to handle
incoming IPC requests.
Bug: 19297165
Change-Id: I39175f3869ad14da5620fddb47f454e6e4ee2b25
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
This makes apps linked against the previous non-static versions
work with the new libbinder.
Bug: 19060033
Bug: 19773812
Change-Id: I3b5c78cbb4f4c0681ca1042e4d8503d98f969502
Michael Wachenschwanz