[RFC] libio FILE/vtable hardening ideas against FSOP-style attacks

Florian Weimer fweimer@redhat.com
Tue Jun 23 07:57:33 GMT 2026


* 류대호:

> 1 Does validating the wide vtable path with IO_validate_vtable seem
>   like a reasonable hardening direction?

GCC 2.95 did not have wide vtable support in libstdc++, so it's unlikely
there is ABI impact.  This means we can replace the vtable pointer with
just an index into a vtable array.  Validation would be a simple bounds
check.  No fallback for old binaries is needed.

> 2 Is exact vtable start-address checking too strict for glibc, or
>   could it be useful in some limited paths?

I think we should try to refactor this eventually and use
switches/conditionals instead of indirect calls for glibc's
implementations.  The only widely used ABI that needs vtables is i386.

A good first step would be to identify the vtables we have, the
functions in them, and how many different implementations those
functions have.

> 3 Is a FILE metadata registry fundamentally incompatible with libio,
>   or is it worth exploring as an optional hardening idea?

Some of the struct members are public, the buffer pointers in
particular.  See getc_unlocked and putc_unlocked.

Thanks,
Florian



More information about the Libc-alpha mailing list