glibc/libio, branch vdso

Fix freopen handling of ,ccs= (bug 23675)

2024-09-05T20:08:10Z

As reported in bug 23675 and shown up in the recently added tests of different cases of freopen (relevant part of the test currently conditioned under #if 0 to avoid a failure resulting from this bug), freopen wrongly forces the stream to unoriented even when a mode with ,ccs= is specified, though such a mode is supposed to result in a wide-oriented stream. Move the clearing of _mode to before the actual reopening occurs, so that the main fopen implementation can leave a wide-oriented stream in the ,ccs= case. Tested for x86_64.

Test fclose on an unopened file.

2024-09-05T13:55:27Z

Add new file libio/tst-fclosed-unopened.c that tests whether fclose on an unopened file returns EOF. Calling fclose on unopened files normally causes a use-after-free bug, however the standard streams are an exception since they are not deallocated by fclose. fclose returning EOF for unopened files is not part of the external contract but there are dependancies on this behaviour. For example, gnulib's close_stdout in lib/closeout.c. Tested for x86_64. Signed-off-by: Aaron Merey

Fix memory leak on freopen error return (bug 32140)

2024-09-05T11:16:59Z

As reported in bug 32140, freopen leaks the FILE object when it returns NULL: there is no valid use of the FILE * pointer (including passing to freopen again or to fclose) after such an error return, so the underlying object should be freed. Add code to free it. Note 1: while I think it's clear from the relevant standards that the object should be freed and the FILE * can't be used after the call in this case (the stream is closed, which ends the lifetime of the FILE), it's entirely possible that some existing code does in fact try to use the existing FILE * in some way and could be broken by this change. (Though the most common case for freopen may be stdin / stdout / stderr, which _IO_deallocate_file explicitly checks for and does not deallocate.) Note 2: the deallocation is only done in the _IO_IS_FILEBUF case. Other kinds of streams bypass all the freopen logic handling closing the file, meaning a call to _IO_deallocate_file would neither be safe (the FILE might still be linked into the list of all open FILEs) nor sufficient (other internal memory allocations associated with the file would not have been freed). I think the validity of freopen for any other kind of stream will need clarifying with the Austin Group, but if it is valid in any such case (where "valid" means "not undefined behavior so required to close the stream" rather than "required to successfully associate the stream with the new file in cases where fopen would work"), more significant changes would be needed to ensure the stream gets fully closed. Tested for x86_64.

Clear flags2 flags set from mode in freopen (bug 32134)

2024-09-05T11:15:29Z

As reported in bug 32134, freopen does not clear the flags set in fp->_flags2 by the "e", "m" or "c" mode characters. Clear these so that they can be set or not as appropriate from the mode string passed to freopen. The relevant test for "e" in tst-freopen2-main.c is enabled accordingly; "c" is expected to be covered in a separately written test (and while tst-freopen2-main.c does include transitions to and from "m", that's not really a semantic flag intended to result in behaving in an observably different way). Tested for x86_64.

libio: Attempt wide backup free only for non-legacy code

2024-09-04T13:29:35Z

_wide_data and _mode are not available in legacy code, so do not attempt to free the wide backup buffer in legacy code. Resolves: BZ #32137 and BZ #27821 Signed-off-by: Siddhesh Poyarekar Reviewed-by: Florian Weimer

ungetc: Fix backup buffer leak on program exit [BZ #27821]

2024-08-15T17:56:13Z

If a file descriptor is left unclosed and is cleaned up by _IO_cleanup on exit, its backup buffer remains unfreed, registering as a leak in valgrind. This is not strictly an issue since (1) the program should ideally be closing the stream once it's not in use and (2) the program is about to exit anyway, so keeping the backup buffer around a wee bit longer isn't a real problem. Free it anyway to keep valgrind happy when the streams in question are the standard ones, i.e. stdout, stdin or stderr. Also, the _IO_have_backup macro checks for _IO_save_base, which is a roundabout way to check for a backup buffer instead of directly looking for _IO_backup_base. The roundabout check breaks when the main get area has not been used and user pushes a char into the backup buffer with ungetc. Fix this to use the _IO_backup_base directly. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Carlos O'Donell

ungetc: Fix uninitialized read when putting into unused streams [BZ #27821]

2024-08-15T17:55:07Z

When ungetc is called on an unused stream, the backup buffer is allocated without the main get area being present. This results in every subsequent ungetc (as the stream remains in the backup area) checking uninitialized memory in the backup buffer when trying to put a character back into the stream. Avoid comparing the input character with buffer contents when in backup to avoid this uninitialized read. The uninitialized read is harmless in this context since the location is promptly overwritten with the input character, thus fulfilling ungetc functionality. Also adjust wording in the manual to drop the paragraph that says glibc cannot do multiple ungetc back to back since with this change, ungetc can actually do this. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Carlos O'Donell

libio/tst-getdelim: Add new test covering NUL as a delimiter

2024-08-14T09:48:34Z

Add a new test to getdelim to verify that '\0' can be set as a delimiter. Reviewed-by: Florian Weimer

Fix name space violation in fortify wrappers (bug 32052)

2024-08-05T14:49:58Z

Rename the identifier sz to __sz everywhere. Fixes: a643f60c53 ("Make sure that the fortified function conditionals are constant")

libio: handle opening a file when all files are closed (bug 31963)

2024-07-09T08:12:36Z

_IO_list_all becomes NULL when all files (including standard files) are closed.