luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-25 15:06:14 +01:00
Code Issues Packages Projects Releases Wiki Activity

gsignal.c: drop an optimization that is undefined behaviour

Browse Source 
Comparing reallocated pointers is UB, but this happens to work for now
on most compilers. However, for CHERI systems if g_bsearch_array_insert()
reallocs in-place then the new `hlbsa` pointer may have larger bounds
than `o` and using the old pointer with the smaller bounds can result
in a bounds error. I don't think this code is performance critical, so
removing the optimization and inserting unconditionally should be fine.

Currently, this realloc() UB rarely causes issues, but newer versions of
GCC with _FORTIFY_SOURCE=3 might also be able to observe the valid
memory range (assuming sufficient inlining).
See https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level
This commit is contained in:
Alex Richardson 2022-12-14 23:55:21 +00:00
parent f9e54fc991
commit 9769cd0d24
1 changed files with 2 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
gobject/gsignal.c
View File

@ -395,17 +395,9 @@ handler_list_ensure (guint signal_id,
if (!hlbsa)
{
hlbsa = g_bsearch_array_create (&g_signal_hlbsa_bconfig);
}
hlbsa = g_bsearch_array_insert (hlbsa, &g_signal_hlbsa_bconfig, &key);
g_hash_table_insert (g_handler_list_bsa_ht, instance, hlbsa);
}
else
{
GBSearchArray *o = hlbsa;
hlbsa = g_bsearch_array_insert (o, &g_signal_hlbsa_bconfig, &key);
if (hlbsa != o)
g_hash_table_insert (g_handler_list_bsa_ht, instance, hlbsa);
}
return g_bsearch_array_lookup (hlbsa, &g_signal_hlbsa_bconfig, &key);
}