There may be a race condition otherwise between release_gdi_font and find_cached_gdi_font, leading to invalid memory access: One thread calling release_gdi_font may decrement refcount to 0, then try to enter font_lock. At the same time, another thread may be calling find_cached_gdi_font through select_font, holding the font_lock. This second thread would find refcount set to 0, and then try to remove unused_entry from its list, although it hasn't been added yet to the unused list. Another possible way to fix this would be to hold the font_lock before decrementing refcount, but that may not be as efficient. Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/win32u/font.c | 1 + 1 file changed, 1 insertion(+) diff --git a/dlls/win32u/font.c b/dlls/win32u/font.c index 1ac48e67d65..c9c9e8ab3b0 100644 --- a/dlls/win32u/font.c +++ b/dlls/win32u/font.c @@ -1994,6 +1994,7 @@ static struct gdi_font *alloc_gdi_font( const WCHAR *file, void *data_ptr, SIZE_ font->matrix.eM11 = font->matrix.eM22 = 1.0; font->scale_y = 1; font->kern_count = -1; + list_init( &font->unused_entry ); list_init( &font->child_fonts ); if (file) -- 2.33.1