The symptom was:
> [..]/expat/tests/alloc_tests.c:326:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 326 | g_allocation_count = i;
> | ^
> [..]/expat/tests/alloc_tests.c:437:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 437 | g_allocation_count = i;
> | ^
> [..]/expat/tests/basic_tests.c:415:47: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 415 | if (_XML_Parse_SINGLE_BYTES(g_parser, text, first_chunk_bytes, XML_FALSE)
> | ^
> [..]/expat/tests/basic_tests.c:421:34: error: narrowing conversion from 'unsigned long' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 421 | sizeof(text) - first_chunk_bytes - 1,
> | ^
> [..]/expat/tests/handlers.c:92:37: error: narrowing conversion from 'XML_Size' (aka 'unsigned long') to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 92 | StructData_AddItem(storage, name, XML_GetCurrentColumnNumber(g_parser),
> | ^
> [..]/expat/tests/handlers.c:93:22: error: narrowing conversion from 'XML_Size' (aka 'unsigned long') to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 93 | XML_GetCurrentLineNumber(g_parser), STRUCT_START_TAG);
> | ^
> [..]/expat/tests/handlers.c:99:37: error: narrowing conversion from 'XML_Size' (aka 'unsigned long') to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 99 | StructData_AddItem(storage, name, XML_GetCurrentColumnNumber(g_parser),
> | ^
> [..]/expat/tests/handlers.c💯22: error: narrowing conversion from 'XML_Size' (aka 'unsigned long') to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 100 | XML_GetCurrentLineNumber(g_parser), STRUCT_END_TAG);
> | ^
> [..]/expat/tests/handlers.c:1279:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 1279 | g_allocation_count = i;
> | ^
> [..]/expat/tests/misc_tests.c:73:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 73 | g_allocation_count = i;
> | ^
> [..]/expat/tests/misc_tests.c:93:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 93 | g_allocation_count = i;
> | ^
> [..]/expat/tests/nsalloc_tests.c:86:26: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 86 | g_allocation_count = i;
> | ^
> [..]/expat/tests/nsalloc_tests.c:526:28: error: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions,-warnings-as-errors]
> 526 | g_reallocation_count = i;
> | ^
The symptom was:
> [..]/expat/tests/handlers.c:135:19: error: function 'strcmp' is called without explicitly comparing result [bugprone-suspicious-string-compare,-warnings-as-errors]
> 135 | if (id != -1 && xcstrcmp(atts[id], info->id_name)) {
> | ^
> | != 0
POSIX strndup() does not read memory beyond NUL byte of the source
string. Preserve this behavior in libexpat implementation to prevent
access violations and keep portability.
m_eventPtr is a key provider to these functions:
- XML_GetCurrentByteCount
- XML_GetCurrentByteIndex
- XML_GetCurrentColumnNumber
- XML_GetCurrentLineNumber
- XML_GetInputContext
The new test asserts that internalEntityProcessor does not loop forever while
processing entities where external entity content references back to internal
entities from the parent document (see &e3; and &e4; below).
We ensure that progress is made after moving the parser from recursive
invocation to a state based processing within function callProcessor.
A version of this test case (originally external-to-Expat, "make run-xmltest")
failed earlier, so we wanted to have a variant of this test (that proved
itself relevant) included within the core test suite ("make check").
Please see commit 60dffa148c
("tests: Use normal XML_Parse in test_suspend_resume_internal_entity")
for more details on the related issue.
In reaction to analysis by Berkay Eren Ürün.
Please see commit 60dffa148c
("tests: Use normal XML_Parse in test_suspend_resume_internal_entity")
for more details on the related issue.
Related tests are:
- test_repeated_stop_parser_between_char_data_calls
- test_reset_in_entity
- test_resume_entity_with_syntax_error
- test_suspend_parser_between_cdata_calls
- test_suspend_parser_between_char_data_calls
- test_suspend_xdecl
In reaction to a finding by Berkay Eren Ürün.
"%e1;" resolves to "%e1;" which resolves to "]><d/>".
Now with c20b758c33 reverted, test case
"inputTwo" has an actual chance of being a false positive parse.
Prior to the fix to XML_StopParser, test test_misc_resumeparser_not_crashing
would crash with a NULL pointer dereference in function normal_updatePosition.
This was the AddressSanitizer output:
> AddressSanitizer:DEADLYSIGNAL
> =================================================================
> ==19700==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x5623e07ad85f bp 0x7ffcf40da650 sp 0x7ffcf40da590 T0)
> ==19700==The signal is caused by a READ memory access.
> ==19700==Hint: address points to the zero page.
> #0 0x5623e07ad85f in normal_updatePosition [..]/lib/xmltok_impl.c:1781:13
> #1 0x5623e07a52ff in initUpdatePosition [..]/lib/xmltok.c:1031:3
> #2 0x5623e0762760 in XML_ResumeParser [..]/lib/xmlparse.c:2297:3
> #3 0x5623e074f7c1 in test_misc_resumeparser_not_crashing() misc_tests_cxx.cpp
> #4 0x5623e074e228 in srunner_run_all ([..]/build_asan_fuzzers/tests/runtests_cxx+0x136228)
> #5 0x5623e0753d2d in main ([..]/build_asan_fuzzers/tests/runtests_cxx+0x13bd2d)
> #6 0x7f802a39af79 (/lib64/libc.so.6+0x25f79)
> #7 0x7f802a39b034 in __libc_start_main (/lib64/libc.so.6+0x26034)
> #8 0x5623e064f340 in _start ([..]/build_asan_fuzzers/tests/runtests_cxx+0x37340)
>
> AddressSanitizer can not provide additional info.
> SUMMARY: AddressSanitizer: SEGV [..]/lib/xmltok_impl.c:1781:13 in normal_updatePosition
> ==19700==ABORTING
And this the UndefinedBehaviorSanitizer output:
> [..]/lib/xmltok_impl.c:1781:13: runtime error: load of null pointer of type 'const char'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior [..]/lib/xmltok_impl.c:1781:13 in
.. to avoid potential reader confusion about where the input character
data is coming from: variable "storage" says that more clearly
and is consistent with multiple other places in the test suite.
Use of g_parser means risk of cross-test interference
and hence risk of hard-to-catch bugs in the test suite,
and so we want to get rid of g_parser altogether midterm.