Age | Commit message (Collapse) | Author |
|
Add casts where necessary to convince clang that the promotion of float
to double is intentional.
Co-authored-by: Sven Linker <sven.linker@kernkonzept.com>
Signed-off-by: Marcus Haehnel <marcus.haehnel@kernkonzept.com>
|
|
Check that the size passed to memalign() is not greater than PTRDIFF_MAX
before adjusting it, otherwise it may wrap around in the adjustment.
This fixes gcc testsuite test gcc.dg/torture/pr60092.c
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
|
|
|
|
Clang warns about the use of old GNU-style designators. To avoid this,
use the C99 designators instead.
|
|
malloc-simple allocator
Two things are fixed by this commit:
1/ It is wrong to allocate an object of size > PTRDIFF_MAX.
It is explained in this thread: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
2/ There was a possible integer overflow in both malloc() and memalign() implementations
of stdlib/malloc-simple.
The malloc() integer overflow issue is fixed by the side effect of fixing the PTRDIFF_MAX issue.
The memalign() one is fixed by adding a comparison.
Signed-off-by: Yann Sionneau <yann@sionneau.net>
|
|
Safe-Linking alignment checks should be done on the user's buffer and not
the mchunkptr. The new check adds support for cases in which:
MALLOC_ALIGNMENT != 2*(sizeof(size_t))
The default case for both 32 bits and 64 bits was already supported, and
this patch adds support for the described irregular case.
|
|
|
|
Safe-Linking is a security mechanism that protects single-linked
lists (such as the fastbins) from being tampered by attackers. The
mechanism makes use of randomness from ASLR (mmap_base), and when
combined with chunk alignment integrity checks, it protects the
pointers from being hijacked by an attacker.
While Safe-Unlinking protects double-linked lists (such as the small
bins), there wasn't any similar protection for attacks against
single-linked lists. This solution protects against 3 common attacks:
* Partial pointer override: modifies the lower bytes (Little Endian)
* Full pointer override: hijacks the pointer to an attacker's location
* Unaligned chunks: pointing the list to an unaligned address
The design assumes an attacker doesn't know where the heap is located,
and uses the ASLR randomness to "sign" the single-linked pointers. We
mark the pointer as P and the location in which it is stored as L, and
the calculation will be:
* PROTECT(P) := (L >> PAGE_SHIFT) XOR (P)
* *L = PROTECT(P)
This way, the random bits from the address L (which start at the bits
in the PAGE_SHIFT position), will be merged with the LSB of the stored
protected pointer. This protection layer prevents an attacker from
modifying the pointer into a controlled value.
An additional check that the chunks are MALLOC_ALIGNed adds an
important layer:
* Attackers can't point to illegal (unaligned) memory addresses
* Attackers must guess correctly the alignment bits
On standard 32 bit Linux machines, an attacker will directly fail 7
out of 8 times, and on 64 bit machines it will fail 15 out of 16
times.
The proposed solution adds 3-4 asm instructions per malloc()/free()
and therefore has only minor performance implications if it has
any. A similar protection was added to Chromium's version of TCMalloc
in 2013, and according to their documentation the performance overhead
was less than 2%.
Signed-off-by: Eyal Itkin <eyalit@checkpoint.com>
|
|
The getenv() library call can trap under certain conditions. It compares the
passed in environment variable name (var) with the name=variables (*ep) in the
environment area and returns a pointer to the value in the environment if it
exists. To accomplish this, it does a memcmp() using the length of the passed
in name (len) for each environment variable (*ep) against the passed in name (
var). So memcmp will attempt to scan both strings for len bytes. However, if
for some reason, len is equal to or greater than 16 and longer than the length
of the *ep in the environment and the *ep resides near the end of a page
boundary while the next page is not present or mapped, the memcmp could trap
with a sigsegv error while continuing the scan with the optimization
read-ahead. However, if strncmp is used instead, there is no problem since both
source and destination scanning will stop when either reaches a terminating
NULL
|
|
The internal heap structures were not protected properly in
memalign(). If multiple threads were concurrently allocating memory and
one of them were requesting aligned memory via valloc,memalign or
posix_memalign the internal heap data structures could be corrupted.
Signed-off-by: Kjetil Oftedal <oftedal@gmail.com>
|
|
This should have been made in commit 9649721950 but was forgotten.
Signed-off-by: Carlos Santos <casantos@datacom.com.br>
|
|
Match glibc behavior.
* libc/stdlib/stdlib.c (mbtowc): Fix end of string behavior.
Signed-off-by: Mickaël Guêné <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
|
|
* libc/stdlib/system.c (FORK): Map to vfork if __ARCH_USE_MMU__
is defined.
Signed-off-by: Mickaël Guêné <mickael.guene@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>
|
|
|
|
|
|
|
|
|
|
OpenBSD arc4random is using chacha20 cipher algorithm for
a long time. This copy is still based on deprecated rc4
cipher algorithm. We could either update the arc4random.c
or drop it. Drop it. Users should better use libbsd when
using arc4random interface. Musl/glibc does not have arc4random
either.
|
|
|
|
sysconf creates a lot of code dependencies.
getpagesize dosen't.
staticly linked code that calls malloc is now much smaller.
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
|
|
All flavors of mkstemp create files with mode S_IRUSR | S_IWUSR, as
per POSIX.1-2008. Make mkostemp64 follow that too instead of creating
files with mode S_IRUSR | S_IWUSR | S_IXUSR.
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
|
|
This follows the recommendations outlined in Network Operations Division
Cryptographic Requirements published on wikileaks on March 2017.
We discard more bytes of the first keystream to reduce possibility of
non-random bytes.
This is similar to a change in FreeBSD:
https://svnweb.freebsd.org/base?view=revision&revision=315225
Signed-off-by: Loganaden Velvindron <logan@hackers.mu>
|
|
|
|
|
|
This option is enabled for a long time and I see no
useful case where we should be incompatible to glibc here.
|
|
|
|
|
|
|
|
Linuxthreads.new isn't really useful with the existence
of NPTL/TLS for well supported architectures. There is no
reason to use LT.new for ARM/MIPS or other architectures
supporting NPTL/TLS. It is not available for noMMU architectures
like Blackfin or FR-V. To simplify the live of the few uClibc-ng
developers, LT.new is removed and LT.old is renamed to LT.
LINUXTHREADS_OLD -> UCLIBC_HAS_LINUXTHREADS
|
|
portability on system with default shell on a different directory, like for instance on android.
Signed-off-by: Ubaldo Porcheddu <ubaldo@eja.it>
|
|
The order of special checks seems critical for some applications.
Xorg 1.18.0 fails to start with XNFreallocarray error.
Took me some time to run with MALLOC_DEBUG=2 to find out.
MALLOC_STANDARD is not affected.
|
|
Invoke pthread_atfork handler cleanup when removing the associated DSO...
If a program loads a DSO (dlopen) that sets up a pthread_atfork handler(s), and
then subsequently closes the DSO, the handler(s) are left in place. If fork()
is subsequently called, the handlers are invoked even though the DSO has been
removed causing crashes or unpredictable code execution. This is because the
code in __cxa_finalize(atexit.c)to invoke the unregister_atfork() routine is
ifdef'd out with the comment that it hasn't been "looked into this yet...".
Refs.:
http://bugs.busybox.net/show_bug.cgi?id=8211
http://sourceware.org/bugzilla/show_bug.cgi?id=13502
Add test-case, enable cleanup for NPTL only.
Signed-off-by: John Ata <john.ata@baesystems.com>
Signed-off-by: Leonid Lisovskiy <lly.dev@gmail.com>
|
|
On avr32/cris the build with MALLOC fails, when compiling
linuxthreads.
|
|
Uclibc's canonicalize_file_name() is allocating temprary buffer of 4kB
(PATH_MAX), and passing it to realpath() as second argument. Function is
not checking if realpath() fails and memory is lost.
|
|
This fix commit 76dfc7ce8c "Some requested additional malloc entry points"
from 2004's
Signed-off-by: Leonid Lisovskiy <lly.dev@gmail.com>
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
This fixes static compile issues of sudo, because sudo
uses it's own getenv implementation.
|
|
Change __gen_tempname() prototype in order to pass the additional
suffix lenght. In __gen_tempname() add a new check for suffixlen.
Update some comments in the code.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
|
|
See discussion here about the issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=12547
Fixes testsuite errors.
|
|
Only the stub warnings left for now.
|
|
|
|
atexit should only be in either uclibc_nonshared.a
shared libc case or libc.a in static build case
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Closes bugzilla #4586
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
For some rarely cases(almost App bugs), calling malloc with
a very largre size, checked_request2size check will fail,set
ENOMEM, and return 0 to caller.
But this will let __malloc_lock futex locked and owned by the
caller. In multithread circumstance, other thread calling
malloc/calloc will NOT succeed and get locked.
Signed-off-by: Zhiqiang Zhang <zhangzhiqiang.zhang@huawei.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
This reverts commit 6b6ede3d15f04fe825cfa9f697507457e3640344.
|
|
|
|
|
|
setenv() in glibc/eglibc will check the argument, like this,
...
if (name == NULL || *name == '\0' || strchr (name, '=') != NULL)
{
__set_errno (EINVAL);
return -1;
}
...
So add argument check in uclibc's setenv() too.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|
|
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
|