IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The getEntity handler was already invoked by xmlParseReference, so it's
useless to call it again. After the recent change, xmlSAX2GetEntity
won't load any kind of entities anyway.
Despite the comment, I can't see a reason why external entities must be
loaded in the SAX handler. For external entities, the handler is
typically first invoked via xmlParseReference which will later load the
entity on its own if it wasn't loaded yet.
The old code also lead to duplicated SAX events which makes it
basically impossible to reuse xmlSAX2GetEntity for a custom SAX parser.
See the change to the expected test output.
Note that xmlSAX2GetEntity was loading the entity via
xmlParseCtxtExternalEntity while xmlParseReference uses
xmlParseExternalEntityPrivate. In the previous commit, the two
functions were merged, trying to compensate for some slight differences
between the two mostly identical implementations.
But the more urgent reason for this change is that xmlParseReference
has the facility to abort early when recursive entities are detected,
avoiding what could practically amount to an infinite loop.
If you want to backport this change, note that the previous three
commits are required as well:
f9ea1a24 Fix copying of entities in xmlParseReference
5c7e0a9a Copy some XMLReader option flags to parser context
1a3e584a Merge code paths loading external entities
Found by OSS-Fuzz.
The parser context stores some options both in the "options" bits and
extra members like "validate" or "replaceEntities". Which of these
are actually read is inconsistent, so make sure to also update the
bit field.
Before, reader mode would end up in a branch that didn't handle
entities with multiple children and failed to update ent->last, so the
hack copying the "extra" reader data wouldn't trigger. Consequently,
some empty nodes in entities are correctly detected now in the test
suite. (The detection of empty nodes in entities is still buggy,
though.)
When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun
alloc a new schema for ctxt->schema and set vctxt->xsiAssemble
to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize
vctxt->xsiAssemble to 0 again which cause the alloced schema
can not be freed anymore.
Found with libFuzzer.
Signed-off-by: Zhipeng Xie <xiezhipeng1@huawei.com>
When a multiple modules (process/plugins) all link to libxml2.dll
they will in fact share a single loaded instance of it.
It is unsafe for any of them to call xmlCleanupParser,
as this would deinitialize the shared state and break others that might
still have ongoing use.
However, on windows atexit is per-module (rather process-wide), so if used
*within* libxml2 it is possible to register a clean up when all users
are done and libxml2.dll is about to actually unload.
This allows multiple plugins to link with and share libxml2 without
a premature cleanup if one is unloaded, while still cleaning up if *all*
such callers are themselves unloaded.
If non-parser parts of libxml (e.g. xmlwriter) are used before a parser,
xmlOnceInit may have run (e.g. via the many paths to xmlGetGlobalState),
but not xmlInitThreads (which is called only by xmlInitParser)
Once globalkey != TLS_OUT_OF_INDEXES (which can happen in many ways),
DLLMAIN(DLL_THREAD_DETACH) may attempt to lock cleanup_helpers_cs
before it is valid. This may happen even if the thread whose exit
is triggering DllMain is from code which is not linked to libxml.
globalkey and cleanup_helpers_cs should be initialized together,
with cleanup_helpers_cs initialized first and deleted last.
Added all test cases that have a non-empty error in result/valid/*.xml.err
Restructured to make it easier extensible with new test cases
Added coding cookie because there is non-ASCII in the error messages
When ctxt->instate == XML_PARSER_EOF,xmlParseStringEntityRef
return NULL which cause a infinite loop in xmlStringLenDecodeEntities
Found with libFuzzer.
Signed-off-by: Zhipeng Xie <xiezhipeng1@huawei.com>
Apparently, some libxslt RVTs can contain nested document nodes, see
issue #132. I'm not sure how this happens exactly but it can cause a
segfault in xmlFreeNodeList after the changes in commit 0762c9b6.
Make sure not to touch the (nonexistent) `content` member of xmlDocs.
One of regressions introduced by commit
2f2bf4b2caa1cb9a4a5039b7a44db101943382d1 aka v2.9.10-rc1~56 is that
cflags and libs variables are used uninitialized, resulting to
the following behaviour:
$ cflags=foo libs=bar sh ./xml2-config.in --prefix
@prefix@
foo bar
Another regression is that the test for these variables is flawed.
Fixes: 2f2bf4b2c ("xml2-config.in: Output CFLAGS and LIBS on the same line")
Minor fix to xmlStringLenGetNodeList to avoid a pointer overflow
during API test.
Enable pointer-overflow and unsigned-integer-overflow sanitizers in CI
tests. Technically, unsigned integer overflows aren't undefined
behavior, but they typically indicate programming errors. Some hash
functions that really require unsigned integer overflows have already
been annotated.
* doc/Makefile.am: xzlib.html seems not generated anymore since it
was only containing an internal define we can drop it
* libxml.spec.in: don't run python tests as part of %check as this
is now breaking on F30
Memory allocation errors in the following functions a often ignored.
Add TODO comments.
- xmlXPathNodeSetCreate
- xmlXPathNodeSetAdd*
- xmlXPathNodeSetMerge*
- xmlXPathNodeSetDupNs
Note that the following functions currently lack a way to propagate
memory errors:
- xmlXPathCompareNodeSets
- xmlXPathEqualNodeSets
Currently, many memory allocation errors in xpath.c aren't propagated to
the parser/evaluation context and for the most part ignored. Most
XPath objects allocated via one of the New, Wrap or Copy functions end
up being pushed on the stack, so adding a check in valuePush handles
many cases without much effort.
Also simplify the code a little and make sure to return -1 in case of
error.
Make sure that memory errors in xmlXPathCompExprAdd are propagated to
the parser context. Hitting the step limit or running out of memory
without raising an error could also lead to an out-of-bounds read.
Also fixes a memory leak in xmlXPathErrMemory.
Found by OSS-Fuzz.
