Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jul 2016 23:17:00 -0400
From: Rich Felker <>
To: Jacob Abrams <>
Subject: Re: vprintf.c bug

On Tue, Jul 26, 2016 at 03:25:40PM -0700, Jacob Abrams wrote:
> I believe there is a small bug in vfprintf.c
> I had to change the if statement from
>     ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
>     if (saved_buf) {
> to
>     ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
>     if (f->buf == internal_buf) {
> Because the saved_buf may be NULL which will result the internal
> buffer being used but the file not being reset properly after the call
> to printf_core. This was discovered while using MUSL v1.1.4 on an OS
> other than Linux.

Where do you get a FILE with a null f->buf? While it's not written
down anywhere, that breaks a contract expected several other places in
the stdio implementation. If you're trying to use vfprintf.c outside
of musl I think you probably need to disable/remove this buffer
replacement code, which would be poking at the internals of another
stdio implementation in a likely-invalid way.


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.