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
next prev parent 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).