mirror of git://git.musl-libc.org/musl
427c0ca79e
1. as reported by William Haddon, the value returned by snprintf was wrongly used as a length passed to sendto, despite it possibly exceeding the buffer length. this could lead to invalid reads and leaking additional data to syslog. 2. openlog was storing a pointer to the ident string passed by the caller, rather than copying it. this bug is shared with (and even documented in) other implementations like glibc, but such behavior does not seem to meet the requirements of the standard. 3. extremely long ident provided to openlog, or corrupt ident due to the above issue, could possibly have resulted in buffer overflows. despite having the potential for smashing the stack, i believe the impact is low since ident points to a short string literal in typical application usage (and per the above bug, other usages will break horribly on other implementations). 4. when used with LOG_NDELAY, openlog was not connecting the newly-opened socket; sendto was being used instead. this defeated the main purpose of LOG_NDELAY: preparing for chroot. 5. the default facility was not being used at all, so all messages without an explicit facility passed to syslog were getting logged at the kernel facility. 6. setlogmask was not thread-safe; no synchronization was performed updating the mask. the fix uses atomics rather than locking to avoid introducing a lock in the fast path for messages whose priority is not in the mask. 7. in some code paths, the syslog lock was being unlocked twice; this could result in releasing a lock that was actually held by a different thread. some additional enhancements to syslog such as a default identifier based on argv[0] or similar may still be desired; at this time, only the above-listed bugs have been fixed. |
||
---|---|---|
arch | ||
crt | ||
dist | ||
include | ||
lib | ||
src | ||
tools | ||
.gitignore | ||
COPYRIGHT | ||
INSTALL | ||
Makefile | ||
README | ||
WHATSNEW | ||
configure |
README
musl libc - a new standard library to power a new generation of Linux-based devices. musl is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety. musl is an alternative to glibc, eglibc, uClibc, dietlibc, and klibc. For reasons why one might prefer musl, please see the FAQ and libc comparison chart on the project website, http://www.musl-libc.org/ For installation instructions, see the INSTALL file. Please refer to the COPYRIGHT file for details on the copyright and license status of code included in musl (standard MIT license). Greetings! The 0.9.x release series for musl features interface coverage for all interfaces defined in ISO C99 and POSIX 2008 base, along with a number of non-standardized interfaces for compatibility with Linux, BSD, and glibc functionality. As the release series progresses, we are gradually adding support for incomplete functionality in existing interfaces, additional functions that are deemed to be important due to their use in real-world software, and support for new library and language features in C11 such as thread-local storage, which is now supported on all targets. In addition, support for additional target cpu architectures is being added. The number of packages build successfully against musl - either out-of-the-box or with minor patches to address portability errors - has exceeded 5000 and is steadily growing. In addition to application compatibility testing, unit testing has been conducted using three separate test frameworks and numerous additional standalone test cases to verify the correctness of the implementation. Included with this package is a gcc wrapper script (musl-gcc) which allows you to build musl-linked programs using an existing gcc 3.x or 4.x toolchain on the host. There are also now at several mini distributions (in the form of build scripts) which provide a self-hosting musl-based toolchain and system root. These are much better options than the wrapper script if you wish to use dynamic linking or build packages with many library dependencies. See the musl website for details. The musl project is actively seeking contributors, mostly in the areas of porting, testing, and application compatibility improvement. For bug reports, support requests, or to get involved in development, please visit #musl on Freenode IRC or subscribe to the musl mailing list by sending a blank email to musl-subscribe AT lists DOT openwall DOT com. Thank you for using musl. Cheers, Rich Felker / dalias