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.
