Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Aug 2021 08:17:38 -0400
From: Rich Felker <>
To: Tamir Duberstein <>
Cc:, Petr Hosek <>
Subject: Re: undefined behavior in getdelim.c

On Sun, Aug 29, 2021 at 06:13:44PM -0400, Tamir Duberstein wrote:
> Fuchsia's libc is derived from musl. We make extensive use of clang
> sanitizers in Fuchsia, and UBSAN has found "applying zero offset to
> null pointer" in getdelim.c.

Thank you for the detailed report!

> Any call to `fopen` followed by a call to `getdelim` will trigger this
> behavior. The UB happens at
> Immediately after `fopen` `f->rpos` is `NULL`; `rpos` won't be
> initialized until a few lines down in `getcunlocked`.

So, a code path where p+=k where p is a null pointer and k is 0,

> Here's the stack trace from UBSAN in Fuchsia:
> .../../zircon/third_party/ulib/musl/src/stdio/getdelim.c:48:13: runtime
> error: applying zero offset to null pointer
>    #0    0x0000432ff5bf0613 in getdelim(char** restrict, size_t*
> restrict, int, FILE* restrict)
> .../../zircon/third_party/ulib/musl/src/stdio/getdelim.c:48
> <>+0x165613
>    #1.2  0x00002380af30fe37 in ubsan_GetStackTrace()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:55 <>+0x3be37
>    #1.1  0x00002380af30fe37 in MaybePrintStackTrace()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:53 <>+0x3be37
>    #1    0x00002380af30fe37 in ~ScopedReport()
> compiler-rt/lib/ubsan/ubsan_diag.cpp:389 <>+0x3be37
>    #2    0x00002380af3141fb in handlePointerOverflowImpl()
> compiler-rt/lib/ubsan/ubsan_handlers.cpp:809
> <>+0x401fb
>    #3    0x00002380af313d6d in
> compiler-rt/lib/ubsan/ubsan_handlers.cpp:815
> <>+0x3fd6d
>    #4    0x0000432ff5bf0613 in getdelim(char** restrict, size_t*
> restrict, int, FILE* restrict)
> .../../zircon/third_party/ulib/musl/src/stdio/getdelim.c:48
> <>+0x165613
> Note that Fuchsia is a years behind, but I've confirmed this UB
> happens even with the latest musl sources.
> Fixing this should be quite straightforward. I'm happy to send a patch
> if you agree.
> Please CC me on response as I am not a subscriber to this mailing list
> per the guidance on

What fix do you have in mind? I believe like 58 is also UB, by virtue
of passing a null pointer to memcpy, albeit with zero length. My first
leaning would be to get rid of the else body at line 32-33 and instead
goto line with getc_unlocked, but the reason that's not already being
done is that the buffer growth code at least originally needed to be
hit before the getc_unlocked. I don't recall immediately if that's
still the case. A very safe approach would be just putting lines 58-60
inside "if (k) { ... }"


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.