[Bug stdio/34019] New: libio: undefined behavior when setbuf on open_memstream

[marocketbd at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=34019

            Bug ID: 34019
           Summary: libio: undefined behavior when setbuf on
                    open_memstream
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: marocketbd at gmail dot com
  Target Milestone: ---

Generally, when user want to write bytes directly into the underlying file,
bypassing glibc FILE buffer wrapper, they can run `setbuf(fp, NULL)` to disable
buffering. When I try to reproduce some IO writing problem, I would like to
disable buffering to perform write operations directly. But when I run
`fputc('A', fp)` against a FILE opened by open_memstream, it crashed, while
another file opened by fmemopen doesn't affect from this.

Digging into code, fmemopen has a "cookie" as underlying buffer.

However, when user trigger setbuf on FILE opened by open_memstream, glibc calls
_IO_default_setbuf to setup, where clears _IO_{read,write}_{base,ptr,end} to
NULL to prepare for later re-initialization. Then write on that FILE calls
_IO_str_overflow, which does not check write pointer, directly dereference on
the pointer, leading to SIGSEGV.

Is that intended? As the document already wrote that the buffer is managed by
libc. If so, I think this should be documented to warn user not to setbuf on
these FILEs opened by open_memstream or open_wmemstream.

---

Quick poc to trigger this problem:

#include <stdio.h>
#include <stddef.h>
int main(void) {
    char *buf = NULL;
    size_t size = 0;
    FILE *fp = open_memstream(&buf, &size);
    char anobuf[32];
    setbuf(fp, anobuf);
    fputc('A', fp); // intended to crash here
    fgetc(fp);
    ungetc('B', fp);
    return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.