aboutsummaryrefslogtreecommitdiff
path: root/qobject/json-parser.c
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2018-08-23 18:40:23 +0200
committerMarkus Armbruster <armbru@redhat.com>2018-08-24 20:26:37 +0200
commit16a485992112be1c8b47b58b0124357db9037093 (patch)
tree3d1200e5c14311b6649416b002e217dbefa209b4 /qobject/json-parser.c
parentada74c3ba1b4f51e4462e186c251eaa974015bb8 (diff)
downloadqemu-16a485992112be1c8b47b58b0124357db9037093.zip
qemu-16a485992112be1c8b47b58b0124357db9037093.tar.gz
qemu-16a485992112be1c8b47b58b0124357db9037093.tar.bz2
json: Improve safety of qobject_from_jsonf_nofail() & friends
The JSON parser optionally supports interpolation. This is used to build QObjects by parsing string templates. The templates are C literals, so parse errors (such as invalid interpolation specifications) are actually programming errors. Consequently, the functions providing parsing with interpolation (qobject_from_jsonf_nofail(), qobject_from_vjsonf_nofail(), qdict_from_jsonf_nofail(), qdict_from_vjsonf_nofail()) pass &error_abort to the parser. However, there's another, more dangerous kind of programming error: since we use va_arg() to get the value to interpolate, behavior is undefined when the variable argument isn't consistent with the interpolation specification. The same problem exists with printf()-like functions, and the solution is to have the compiler check consistency. This is what GCC_FMT_ATTR() is about. To enable this type checking for interpolation as well, we carefully chose our interpolation specifications to match printf conversion specifications, and decorate functions parsing templates with GCC_FMT_ATTR(). Note that this only protects against undefined behavior due to type errors. It can't protect against use of invalid interpolation specifications that happen to be valid printf conversion specifications. However, there's still a gaping hole in the type checking: GCC recognizes '%' as start of printf conversion specification anywhere in the template, but the parser recognizes it only outside JSON strings. For instance, if someone were to pass a "{ '%s': %d }" template, GCC would require a char * and an int argument, but the parser would va_arg() only an int argument, resulting in undefined behavior. Avoid undefined behavior by catching the programming error at run time: have the parser recognize and reject '%' in JSON strings. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20180823164025.12553-57-armbru@redhat.com>
Diffstat (limited to 'qobject/json-parser.c')
-rw-r--r--qobject/json-parser.c12
1 files changed, 10 insertions, 2 deletions
diff --git a/qobject/json-parser.c b/qobject/json-parser.c
index 273f448..63e9229 100644
--- a/qobject/json-parser.c
+++ b/qobject/json-parser.c
@@ -144,7 +144,8 @@ static QString *parse_string(JSONParserContext *ctxt, JSONToken *token)
while (*ptr != quote) {
assert(*ptr);
- if (*ptr == '\\') {
+ switch (*ptr) {
+ case '\\':
beg = ptr++;
switch (*ptr++) {
case '"':
@@ -205,7 +206,14 @@ static QString *parse_string(JSONParserContext *ctxt, JSONToken *token)
parse_error(ctxt, token, "invalid escape sequence in string");
goto out;
}
- } else {
+ break;
+ case '%':
+ if (ctxt->ap) {
+ parse_error(ctxt, token, "can't interpolate into string");
+ goto out;
+ }
+ /* fall through */
+ default:
cp = mod_utf8_codepoint(ptr, 6, &end);
if (cp < 0) {
parse_error(ctxt, token, "invalid UTF-8 sequence in string");