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

[alexandre.ferrieux@orange.com]

On 26/04/2024 21:16, Florian Weimer wrote:
> 
> * alexandre ferrieux:
> 
>> Now, I still have worries about the symbol versioning approach: why
>> restrict the version bump to _IO_un_link and _IO_link_in ? Indeed, any
>> program calling fclose()  ends up calling _IO_un_link(), so the
>> version check should apply too, right ? So shouldn't we tag all
>> functions using (FILE *) in their arguments or return value ?
> 
> No new symbol versions should be needed.  You just need to be careful
> not to access that part of the struct when it does not exist.
> 
> I think the way to check for old-style streams is via _IO_vtable_offset,
> as can be seen at the start of the __fgetln function in an (unmerged)
> patch I submitted a while back:
> 
>    [PATCH] stdio-common: Add the fgetln function
>    <https://inbox.sourceware.org/libc-alpha/871qxbxe2i.fsf@oldenburg.str.redhat.com/>
> 
> In your case, you would have to do the full traversal once you encounter
> a missing backlink.  But that would only happen if old-style file
> handles are actually used.  Maybe this is even easier to implement than
> the hash table or index approach.

Thanks for pointing me in the right direction. Now I see I need a runtime check 
for each individual file pointer on the list, as one cannot exclude a scenario 
where a (disgusting) old binary would malloc a decades-old variant of FILE, and 
stick it to the head of the list through an innocent _IO_link_in().

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 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 ?

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.