diff options
author | Ben Chan <benchan@chromium.org> | 2017-08-11 15:17:30 -0700 |
---|---|---|
committer | Aleksander Morgado <aleksander@aleksander.es> | 2017-08-15 09:37:24 +0200 |
commit | 7ae32d6c61b7bd611b5b18626204f51d178b4b11 (patch) | |
tree | 7a883c4bc208973a26b562abbda0c71deeb4f749 /src/mm-device.c | |
parent | d639359320736dd582a2dbb5c50039a8a1b878da (diff) |
charset: fix mm_charset_get_encoded_len
The while loop in mm_charset_get_encoded_len() iterates through each
valid UTF-8 encoded character in the given NULL-terminated UTF-8 string.
It uses g_utf8_find_next_char() to find the position of the next
character. In case, g_utf8_find_next_char() returns NULL, it tries to
find the end (i.e. the NULL character) of the string.
This patch fixes the following issues in the while loop:
1. The loop uses both 'next' and 'end' to track the position of the next
character in the string.
When g_utf8_find_next_char() returns a non-NULL value, 'next' is
essentially the same as 'end'.
When g_utf8_find_next_char() returns NULL, 'next' remains NULL while
'end' is adjusted to track the end of the string (but is done
incorrectly as described in #2). After the 'p = next' assignment, the
'while (*p)' check results in a NULL dereference. 'p' should thus be
set to 'end' instead of 'next'.
'next' is thus redundant and can be removed.
2. When g_utf8_find_next_char() returns NULL and 'end' is adjusted to
track the end of string, the 'while (*end++)' loop stops when finding
the NULL character, but 'end' is advanced past the NULL character.
After the 'p = end' assignment, the 'while (*p)' check results in a
dereference of out-of-bounds pointer.
'while (*++end)' should be used instead given that 'p' doesn't point
to a NULL character when 'end = p' happens. 'end' will be updated to
point to the NULL character. After the 'p = end' assignment (fixed in
#1), the 'while (*p)' check will properly stop the loop.
Diffstat (limited to 'src/mm-device.c')
0 files changed, 0 insertions, 0 deletions