Re: FreeType Cache abuses

On 17/04/2026 10:47, Alexei Podtelezhnikov wrote:
> We've recently received two reports with potential security
> implications when FreeType Cache is abused in very specific and
> unusual ways.
> 
> https://gitlab.freedesktop.org/freetype/freetype/-/work_items/1401
> https://gitlab.freedesktop.org/freetype/freetype/-/work_items/1418
> 
> In both cases, first the lookup functions are called to obtain the
> FTC_Node reference pointer as the last argument. Then the cache is
> forced to abandon and free the node leaving the dangling pointer. At
> last, the user triggers use-after-free.
> 
> We can certainly provide some protections against these abuses but is
> it really worth it? Is it really FreeType's fault or the user's who
> actually triggers use-after-free at last?
> 
> Werner will shortly lift the confidential flag. We would appreciate
> your feedback and assessment from the local security experts.

I can't get access to the above links, so please bear with me.

If I'm understanding this correctly, someone is calling a function which 
(maybe indirectly) returns a pointer to an internal cached piece of storage.

Then something else happens which causes that storage to be freed.

If the user then accesses the storage, that's a use after free.

It strikes me that this is the kind of thing that is implicit within C. 
A caller is free to access any memory he/she may like. We can't guard 
against any such bad decisions the caller might make.

All we can do is to ensure that the caller has the appropriate 
information to allow him/her to act in a safe manner.

So, as long as when we return a pointer to the cached information, we 
are clear about what the lifespan of that information is, we're safe.

i.e. if we can say "This data is guaranteed to be intact until at least 
point X in the future" (where point X might be "when you next call 
freetype", or something more complex), then that's part of the spec.

Then the user has a clear contract, and can behave safely. If he/she 
chooses to ignore this, then the fault is his.

If we can't give such a clear contract, then the fault is ours!

IMHO, etc.

Robin