The overflow's actually in the generic C implementation of memchr.
While I'm here, let's switch our generic memrchr to the OpenBSD version too.
Bug: https://code.google.com/p/android/issues/detail?id=147048
Change-Id: I296ae06a1ee196d2c77c95a22f11ee4d658962da
We already had the POSIX strerror_r, but some third-party code defines
_GNU_SOURCE and expects to get the GNU strerror_r instead.
This exposed a bug in the libc internal logging functions where unlike
their standard brethren they wouldn't return the number of bytes they'd
have liked to have written.
Bug: 16243479
Change-Id: I1745752ccbdc569646d34f5071f6df2be066d5f4
Reduce randomization of the test by (1) replacing random() & 255
with hard-coded char and (2) by making State *Iteration function
visit every possible alignment combination instead of 10 random ones.
Change-Id: I0ff0b4ca817ba9fbbcce53e09b25eb10a1a853c2
The memchr implementation for 64 bit fails if these conditions occur:
- The buffer is 32 byte aligned.
- The buffer contains the character in the first byte.
- The count sent in is zero.
The function should return NULL, but it's not.
Bug: 16676625
Change-Id: Iab33cc7a8b79920350c72f054dff0e0a3cde69ce
These were removed from POSIX 2004. Hides the header declarations for all
targets, and hides the symbols for LP64.
Bug: 13935372
Change-Id: Id592f67e9b7051517a05f536e1373b30162e669c
__memcmp16() should return an integer less than, equal to, or greater than
zero. However the tests looks for a specific value.
Change-Id: I06052f58f9ccc67146a3df9abb349c4bc19f090e
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
Introduce a test for memmove that catches a fault.
Fix both 32- and 64-bit versions of slm-tuned memmove.
Change-Id: Ib416def2610a0972e32c3b9b6055b54967643dc3
Signed-off-by: Varvara Rainchik <varvara.rainchik@intel.com>
__SIGRTMIN will continue to tell the truth. This matches glibc's
behavior (as evidenced by the fact that we don't need a special case
in the strsignal test now).
Change-Id: I1abe1681d516577afa8cd39c837ef12467f68dd2
Add tests for the above.
Add the fortify implementations of __stpcpy_chk and __stpncpy_chk.
Modify the strncpy test to cover more cases and use this template for
stpncpy.
Add all of the fortify test cases.
Bug: 13746695
Change-Id: I8c0f0d4991a878b8e8734fff12c8b73b07fdd344
In order to be able to generate a list of tests for cts, the same set of
tests must exist across all platforms. This CL adds empty tests where a
test was conditionally compiled out.
This CL creates a single library libBionicTests that includes all of
the tests found in bionic-unit-tests-static.
Also fix a few missing include files in some test files.
Tested by running and compiling the tests for every platform and
verifying the same number of tests are on each platform.
Change-Id: I9989d4bfebb0f9c409a0ce7e87169299eac605a2
Create a few generic testing functions to allow any memory/string tests
to be created.
Add alignment tests for memcpy/memset/strcat/strcpy/strlen.
Add an overread test for memcpy/strcat/strcpy/strlen. This test attempts
to verify that the functions do not read past the end of their buffers
(src buffer in the case of src/dst functions).
Bug: 9797008
Change-Id: Ib3223ca1b99e729ae8229adc2d03f4dc3103d97c
__memcmp16 was missing in x86. Also added C-version for backward
compatibility. Added bionic test for __memcmp16 and for wmemcmp.
Change-Id: I33718441e7ee343cdb021d91dbeaf9ce2d4d7eb4
Signed-off-by: Alexander Ivchenko <alexander.ivchenko@intel.com>
__strcat_chk and __strncat_chk are slightly inefficient,
because they end up traversing over the same memory region
two times.
This change optimizes __strcat_chk / __strncat_chk so they
only access the memory once. Although I haven't benchmarked these
changes, it should improve the performance of these functions.
__strlen_chk - expose this function, even if -D_FORTIFY_SOURCE
isn't defined. This is needed to compile libc itself without
-D_FORTIFY_SOURCE.
Change-Id: Id2c70dff55a276b47c59db27a03734d659f84b74
Add support for fortify source level 2 to strncpy.
This will enable detection of more areas where strncpy
is used inappropriately. For example, this would have detected
bug 8727221.
Move the fortify_source tests out of string_test.cpp, and
put it into fortify1_test.cpp.
Create a new fortify2_test.cpp file, which copies all
the tests in fortify1_test.cpp, and adds fortify_source level
2 specific tests.
Change-Id: Ica0fba531cc7d0609e4f23b8176739b13f7f7a83
Don't do the fortify_source checks if we can determine, at
compile time, that the provided operation is safe.
This avoids silliness like calling fortify source on things like:
size_t len = strlen("asdf");
printf("%d\n", len);
and allows the compiler to optimize this code to:
printf("%d\n", 4);
Defer to gcc's builtin functions instead of pointing our code
to the libc implementation.
Change-Id: I5e1dcb61946461c4afaaaa983e39f07c7a0df0ae
e6e60065ff modified strerror_r to
treat errno as signed. However, the change to the test code
modified the "strerror" test, not the "strerror_r" test.
Make the same change for the strerror_r code.
Change-Id: Ia236a53df5745935e229a4446a74da8bed0cfd7b
Add a test to ensure that stack canaries are working
correctly. Since stack canaries aren't normally generated
on non-string functions, we have to enable stack-protector-all.
Add a test to ensure that an out of bounds strcpy generates
a runtime failure.
Change-Id: Id0d3e59fc4b9602da019e4d35c5c653e1a57fae4
Based on a pair of patches from Intel:
https://android-review.googlesource.com/#/c/43909/https://android-review.googlesource.com/#/c/44903/
For x86, this patch supports _both_ the global that ARM/MIPS use
and the per-thread TLS entry (%gs:20) that GCC uses by default. This
lets us support binaries built with any x86 toolchain (right now,
the NDK is emitting x86 code that uses the global).
I've also extended the original tests to cover ARM/MIPS too, and
be a little more thorough for x86.
Change-Id: I02f279a80c6b626aecad449771dec91df235ad01
I gave up trying to use the usual thread-local buffer idiom; calls to
calloc(3) and free(3) from any of the "dl" functions -- which live in
the dynamic linker -- end up resolving to the dynamic linker's stubs.
I tried to work around that, but was just making things more complicated.
This alternative costs us a well-known TLS slot (instead of the
dynamically-allocated TLS slot we'd have used otherwise, so no difference
there), plus an extra buffer inside every pthread_internal_t.
Bug: 5404023
Change-Id: Ie9614edd05b6d1eeaf7bf9172792d616c6361767
