This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/21393] Missing dup3 error check in freopen, freopen64


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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  f1a67a2c78601599be51a17250ca02c7d830d79d (commit)
      from  d26db8fbb4787905590f207d56026e915b3bd5b3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f1a67a2c78601599be51a17250ca02c7d830d79d

commit f1a67a2c78601599be51a17250ca02c7d830d79d
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Fri May 5 11:31:38 2017 -0300

    libio: Avoid dup already opened file descriptor [BZ#21393]

    As described in BZ#21398 (close as dup of 21393) report current
    freopen implementation fails when one tries to freopen STDIN_FILENO,
    STDOUT_FILENO, or STDERR_FILENO.  Although on bug report the
    discussion leads to argue if a close followed by a freopen on the
    standard file is a valid operation, the underlying issue is not
    really the check for dup3 returned value, but rather calling it
    if the returned file descriptor is equal as the input one.

    So for a quality of implementation this patch avoid calling dup3
    for the aforementioned case.  It also adds a dup3 error case check
    for the two possible failures, with one being Linux only: EINTR and
    EBUSY.  The EBUSY issue is better explained on this stackoverflow
    thread [1], but in a short it is due the internal Linux
    implementation which allows a race condition window for dup2 due
    the logic dissociation of file descriptor allocation and actual
    VFS 'install' operation.  For both outliers failures all allocated
    memory is freed and a NULL FILE* is returned.

    With this patch the example on BZ#21398 is now actually possible
    (I used as the testcase for the bug report).  Checked on
    x86_64-linux-gnu.

        [BZ #21393]
        * libio/freopen.c (freopen): Avoid dup already opened file descriptor
        and add a check for dup3 failure.
        * libio/freopen64.c (freopen64): Likewise.
        * libio/tst-freopen.c (do_test): Rename to do_test_basic and use
        libsupport.
        (do_test_bz21398): New test.
        * manual/stdio.texi (freopen): Add documentation of EBUSY failure.

    [1]
http://stackoverflow.com/questions/23440216/race-condition-when-using-dup2

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog           |   11 +++++
 libio/freopen.c     |   22 +++++++++--
 libio/freopen64.c   |   22 +++++++++--
 libio/tst-freopen.c |  107 +++++++++++++++++++++++++++------------------------
 manual/stdio.texi   |   10 ++++-
 5 files changed, 113 insertions(+), 59 deletions(-)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]