Commit aead1c04 authored by Committed by Allison KarlitskayaBrowse files
GVariant text: fix scan of positional parameters
The scanning to find the end of a positional parameter designator in GVariant text format (e.g. '%i') is currently broken in case the 'end' pointer is not specified. The scan is controlled by a somewhat complicated loop that needs to deal properly with cases like (123, %(ii)) [where '%(ii)' is to be taken together, but the final ')' not]. This loop missed the case where a format string passed to g_variant_new_parsed() ended immediately after such a conversion, with a nul character. In this case the 'end' pointer is NULL, so the only way we can find the end is by scanning for nul in the string. In case of g_variant_new_parsed() [which is what this code was designed to be used for], the bug is somewhat unlikely in practice: the only way that a valid text-form GVariant could ever contain a positional parameter replacement at the end of the string is if this positional parameter were the only thing being returned. In that case, the user would likely have opted for a more direct approach. Unfortunately, this code is also active in the tokenisation phase of g_variant_parse(), before positional parameters are rejected as invalid for that case. Anyone who calls this function with a nul-terminated string (and no end pointer) is vulnerable to a crash from malicious user input. This can be seen, at the very least with many commandline tools: $ dconf write /x '%i' Segmentation fault We fix this problem by searching for the nul character in this case, in addition to comparing the end pointer. This problem is almost certainly limited to being able to cause crashes. The loop in question only performs reads and, in the security-sensitive case, the token will be quickly rejected after the loop is finished (since it starts with '%' and the 'app' pointer is unset). This is further mitigated by the fact that there are no known cases of GVariant text format being used as part of a protocol at a privilege barrier.