diff options
author | Markus Armbruster <armbru@redhat.com> | 2018-08-23 18:40:23 +0200 |
---|---|---|
committer | Markus Armbruster <armbru@redhat.com> | 2018-08-24 20:26:37 +0200 |
commit | 16a485992112be1c8b47b58b0124357db9037093 (patch) | |
tree | 3d1200e5c14311b6649416b002e217dbefa209b4 /qobject/json-parser.c | |
parent | ada74c3ba1b4f51e4462e186c251eaa974015bb8 (diff) | |
download | qemu-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.c | 12 |
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"); |