GNOME Bugzilla – Bug 738042
Unsafe UTF-8 output of g_locale_to_utf8(), g_filename_to_utf8()
Last modified: 2018-02-01 14:11:38 UTC
The implementation of g_{locale,filename}_to_utf8(), in case the source encoding is not UTF-8, hands the job off to iconv() without checking if the output has any NUL bytes within its length. This seems to violate the safety contract on UTF-8 strings in GLib as enforced by g_utf8_validate() in the UTF-8 path.
Created attachment 287889 [details] [review] glib/gconvert.c: Don't allow inner NUL into UTF-8 conversion results In the UTF-8 conversion functions, g_locale_to_utf8() and g_filename_to_utf8(), the code path taken in case of a non-UTF-8 source charset simply called g_convert(). That being a thin wrapper over iconv(), it allows NUL characters into the output if the source string supplies them. So for *to_utf8() routines, the output strings should be checked for NUL bytes within their stated length.
Created attachment 287890 [details] [review] glib/gconvert.c: Remove dead, wrong code In strdup_len(), the string with a specified length is vetted by g_utf8_validate() before being copied out. As g_utf8_validate() invalidates inner NULs, it makes no sense to search for them afterwards.
This was fixed as bug #792516, by yourself; sorry for your previous efforts here being ignored for 3 years! *** This bug has been marked as a duplicate of bug 792516 ***