Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 30 Apr 2013 18:34:23 +0200
From: Szabolcs Nagy <>
Subject: Re: Word-sized reads access memory past the bound of objects

* Rich Felker <> [2013-04-30 11:40:45 -0400]:
> On Tue, Apr 30, 2013 at 05:11:14PM +0200, Jonas Wagner wrote:
> > - Are there other types of "soft" undefined behavior that MUSL exploits?
> I don't think so. The closest things I can think of:
> - UTF-8 code depends on sign-extending right-shift. This could be
>   easily fixed if it can be verified that the standard trick to work
>   around it generates the same (or equally efficient) code. Note this
>   is implementation-defined, not undefined.

there are similar cases in src/math
(implementation defined signed int arithmetics)
although those are not intentional and are planned
to be cleaned up (they came from fdlibm of freebsd)

> - Floating point conversion to/from strings depends on IEEE arithmetic
>   properties and on long double being an IEEE conforming type. (x87
>   ld80 is fine, so is IEEE quad, but IBM double-double will not work,
>   and systems that typically use IBM double-double should instead have
>   their compiler configured for 64-bit long double instead.)
> - calloc assumes its own implementation of malloc. Compilers and
>   analysis tools which assume negative offsets from the pointer
>   returned by malloc are invalid will falsely detect problems and/or
>   miscompile calloc.c. This issue affected old versions of clang.
> - The dynamic linker also makes some assumptions about the
>   implementation of malloc and passes pointers not obtained by malloc
>   to free, as part of its mechanism to reclaim wasted slack space in
>   shared libraries due to page alignment.
> - POSIX timers with SIGEV_THREAD perform a longjmp out of a
>   cancellation handler to intercept cancellation/exit so the same
>   physical thread can be kept to handle the next timer expiration. For
>   an application to do this would be UB (at the POSIX level, not the C
>   level) but since they're both part of the same implementation they
>   can assume things about each other.
> That's all that comes to mind right now. Thanks for bringing up this
> question, because it's something that should be documented in case
> people want to reuse parts of musl in contexts where some of the
> assumptions may no longer be valid.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.