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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If a document is parsed with XML_PARSE_DTDVALID and without
XML_PARSE_NOENT, the value of ID attributes has to be normalized after
potentially expanding entities in xmlRemoveID. Otherwise, later calls
to xmlGetID can return a pointer to previously freed memory.
ID attributes which are empty or contain only whitespace after
entity expansion are affected in a similar way. This is fixed by
not storing such attributes in the ID table.
The test to detect streaming mode when validating against a DTD was
broken. In connection with the defects above, this could result in a
use-after-free when using the xmlReader interface with validation.
Fix detection of streaming mode to avoid similar issues. (This changes
the expected result of a test case. But as far as I can tell, using the
XML reader with XIncludes referencing the root document never worked
properly, anyway.)
All of these issues can result in denial of service. Using xmlReader
with validation could result in disclosure of memory via the error
channel, typically stderr. The security impact of xmlGetID returning
a pointer to freed memory depends on the application. The typical use
case of calling xmlGetID on an unmodified document is not affected.
This file was undocumented and never used anywhere. Maybe users were
supposed to rename this file to xmlversion.h manually. These days, both
CMake and win32/configure.js generate xmlversion.h from xmlversion.h.in,
just like the Autotools build.
The children member of entity reference nodes points to the entity
declaration and must never be followed when traversing a tree. In
the worst case, this could lead to an infinite loop.
It's somewhat unclear how moving entity references to other documents
should work exactly. For now we simply set the children pointer to NULL
to avoid a reference to the original document.
Fixes#42.
Client code should never add document nodes as children of other nodes,
but even our own XPointer code has a bug that can produce such trees.
Make sure to really free nested documents. Also see commits 0815302d
and 0762c9b6.
Should fix#269.
For historical reasons, the string API operates with int indices which
can overflow, especially on 64-bit systems. libxml2 always made the
tacit assumption that strings will be never larger than INT_MAX bytes.
It should be considered a bug if any part of the code can produce
larger strings, whether they are externally visible or not.
Likewise, API users are expected not to supply strings larger than
INT_MAX bytes. This requirement isn't documented. But even if it was,
we must handle larger strings passed in by accident without causing
memory errors.
- xmlStrndup, xmlCharStrndup, xmlUTF8Strndup
Avoid integer overflow if len == INT_MAX.
- xmlStrlen, xmlUTF8Strsize, xmlUTF8Strloc
Avoid integer overflow by using size_t for index. If an input string
larger than INT_MAX bytes is detected, these functions now return 0
instead of a wrong and possibly negative value.
- xmlCheckUTF8
Avoid integer overflow by limiting index range.
- xmlStrncat, xmlStrncatNew, xmlEscapeFormatString
Avoid integer overflow. Return NULL instead of producing strings
larger than INT_MAX bytes.
This enables the remaining checks from the "integer" group:
- implicit-unsigned-integer-truncation
- implicit-signed-integer-truncation
- implicit-integer-sign-change
These checks can find all kinds of bugs and only require explicit casts
if integer truncation or sign change is really intended.
Use unsigned long for temporary variable to avoid integer conversion
warnings with UBSan.
Note that this does change the computation of hash values for input
bytes larger than 0x7F. Before, these bytes were first converted to a
(typically) signed char with a negative value, then to a large unsigned
long near ULONG_MAX. I doubt that this was intentional. Input bytes
larger than 0x7F are now converted to unsigned long unchanged.
