public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Shamil Abdulaev <ashamil435@gmail.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] libio: Fix race in _IO_new_file_init_internal initialization order [BZ #33785]
Date: Wed, 29 Apr 2026 10:29:32 +0200	[thread overview]
Message-ID: <lhuqznyuq37.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <94933ea56cf84f067c5e7bb7a67eb39f9d9384c0.1777424201.git.ashamil435@gmail.com> (Shamil Abdulaev's message of "Wed, 29 Apr 2026 03:58:12 +0300")

* Shamil Abdulaev:

> _IO_new_file_init_internal linked the new stream into _IO_list_all
> before setting fp->_fileno to -1.  A concurrent thread that walks
> _IO_list_all (for example via fflush (NULL)) could observe the stream
> with an uninitialized _fileno before initialization completed.
>
> Set _fileno = -1 before _IO_link_in so the stream is fully
> initialized when it becomes visible in the global list.
>
> This is the residual concurrency defect noted at the end of commit
> b657f72fa3 ("libio: Fix deadlock between freopen, fflush (NULL) and
> fclose (bug 24963)").
>
> Add libio/tst-file-init-race exercising concurrent fopen/fclose and
> fflush (NULL) to detect regressions.
>
> Signed-off-by: Shamil Abdulaev <ashamil435@gmail.com>
> ---
>  libio/Makefile             |  3 ++
>  libio/fileops.c            |  2 +-
>  libio/tst-file-init-race.c | 66 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 70 insertions(+), 1 deletion(-)
>  create mode 100644 libio/tst-file-init-race.c
>
> diff --git a/libio/Makefile b/libio/Makefile
> index 93656466df..7e448295e3 100644
> --- a/libio/Makefile
> +++ b/libio/Makefile
> @@ -107,6 +107,7 @@ tests = \
>    tst-fgetc-after-eof \
>    tst-fgetwc \
>    tst-fgetws \
> +  tst-file-init-race \
>    tst-fopenloc2 \
>    tst-fputws \
>    tst-freopen \
> @@ -160,6 +161,8 @@ tests-static += \
>  
>  $(objpfx)tst-popen-fork: $(shared-thread-library)
>  
> +$(objpfx)tst-file-init-race: $(shared-thread-library)
> +
>  tests-internal = tst-vtables tst-vtables-interposed
>  
>  ifeq (yes,$(build-shared))
> diff --git a/libio/fileops.c b/libio/fileops.c
> index 8067c0a9cf..9348d7c3a1 100644
> --- a/libio/fileops.c
> +++ b/libio/fileops.c
> @@ -111,8 +111,8 @@ _IO_new_file_init_internal (struct _IO_FILE_plus *fp)
>    fp->file._offset = _IO_pos_BAD;
>    fp->file._flags |= CLOSED_FILEBUF_FLAGS;
>  
> -  _IO_link_in (fp);
>    fp->file._fileno = -1;
> +  _IO_link_in (fp);
>  }

Thanks for investigating this and fixing it.

Would you please apply the parallel change to libio/oldfileops.c?  It
looks like it has the same bug.

Florian


  reply	other threads:[~2026-04-29  8:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-29  0:58 Shamil Abdulaev
2026-04-29  8:29 ` Florian Weimer [this message]
2026-04-29  8:34 ` Florian Weimer
2026-04-29 14:29 ` [PATCH v2] " Shamil Abdulaev
2026-05-06 18:50   ` Florian Weimer
2026-05-06 19:20     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=lhuqznyuq37.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=ashamil435@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).