Re: [PATCH] Fix #27777 - now use a doubly-linked list for _IO_list_all

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Apr 29, 2024 at 7:47 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Mon, Apr 29, 2024 at 12:05 PM <alexandre.ferrieux@orange.com> wrote:
> >
> > On 29/04/2024 15:20, Florian Weimer wrote:
> > >
> > > * alexandre ferrieux:
> > >
> > >> To do this in a robust manner, how about using _flags2 ?
> > >> (I see _flags has one value left, 0x4000, but it's "reserved for compat"... too bad)
> > >>
> > >> Something like:
> > >>
> > >>   #define _IO_FLAGS2_HAS_PREVCHAIN 256
> > >>
> > >>   void      _IO_old_init (FILE *fp, int flags)      {
> > >>      ...
> > >>      fp->flags2 |= _IO_FLAGS2_HAS_PREVCHAIN ;
> > >>   }
> > >>
> > >>   void __stdfiles_init(void)
> > >>   {
> > >>      ...
> > >>      (**f).flags2 |= _IO_FLAGS2_HAS_PREVCHAIN ;
> > >>   }
> > >>
> > >>
> > >> Then, (fp->flags2&_IO_FLAGS2_HAS_PREVCHAIN) becomes a reliable
>
> This won't work for copy relocation in old binaries.
>
> > >> criterion for _IO_link_in and _IO_un_link to decide whether to use the
> > >> new algorithm or the old one.
> > >>
> > >> What do you think ?
> > >
> > > I believe you can use the vtable_offset field as that flag.  See this
> > > code in stdio-common/vfprintf-internal.c:
> > >
> > >      133
> > >      134 # define ORIENT         if (_IO_vtable_offset (s) == 0 && _IO_fwide (s,
> > >      134  -1) != -1)\
> > >      135                           return -1
> >
> > Why is it sufficient ? Doesn't the nullity of the vtable_offset identify a
> > different point in versions history ?
> >
> > An "old binary", recent enough to have the modern vtable_offset, but compiled
> > with the include files just before the patch, can presumably create an old
> > _IO_FILE, insert it "by hand" into _IO_list_all, *not* updating the prevchain of
> > the next-in-line, and then crash when the latter is closed.
> >
>
> Here is a patch with _IO_vtable_offset (s) == 0 check.
>

Here is the updated patch with a testcase:

https://patchwork.sourceware.org/project/glibc/list/?series=33314

-- 
H.J.