""" The xmlBuildQName function in tree.c is vulnerable to an integer overflow when calculating the required buffer size for concatenating a prefix and a local name (ncname). The lengths of ncname and prefix are retrieved using strlen (which returns size_t) but are then implicitly cast to int variables lenn and lenp. ... The PoC provided (and its ASan output) successfully demonstrated the second scenario, causing a stack buffer overflow by writing approximately 2GB (INT_MAX - 10 bytes) into a 100-byte stack buffer passed as the memory argument. """ Fortunately, not much seems to use the affected function: https://gitlab.gnome.org/GNOME/libxml2/-/issues/926#note_2453434.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5588907f80bd111e17758384d990e271f60e555 commit e5588907f80bd111e17758384d990e271f60e555 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-06-16 19:45:34 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-06-16 19:45:34 +0000 dev-libs/libxml2: add 2.14.4 Bug: https://bugs.gentoo.org/958276 Signed-off-by: Sam James <sam@gentoo.org> dev-libs/libxml2/Manifest | 1 + dev-libs/libxml2/libxml2-2.14.4.ebuild | 183 +++++++++++++++++++++++++++++++++ 2 files changed, 184 insertions(+)
2.13.x at least seems affected too but not sure why upstream haven't backported it to that branch.
(In reply to Sam James from comment #2) > 2.13.x at least seems affected too but not sure why upstream haven't > backported it to that branch. Ah, it doesn't apply cleanly because of malloc function changes.
(In reply to Sam James from comment #3) > (In reply to Sam James from comment #2) > > 2.13.x at least seems affected too but not sure why upstream haven't > > backported it to that branch. > > Ah, it doesn't apply cleanly because of malloc function changes. 2.13.x won't get a new release probably: https://discourse.gnome.org/t/libxml2-2-13-eol/28971/3
