On Mon, 2026-08-24 at 15:20 +0000, Jakub Szczudlo (Nokia) wrote:
> Expat does not track whether its public parser APIs are called from inside
> a user handler. Re-entering the parser through XML_GetBuffer(),
> XML_Parse(), XML_ParseBuffer(), XML_ParserFree() or XML_ParserReset() can
> therefore result in use-after-free and memory corruption.
> The 32 upstream commits are divided as follows:
> * 01 introduces the handler call depth counter and the helper functions
> used to enter, leave and detect handler execution.
> * 02-04 are preparation patches. They extract handler calls from compound
> expressions so that depth tracking can be placed before and after each
> invocation without changing handler return-value semantics.
> * 05-26 instrument the individual handler types. Each patch covers a
> distinct callback path; omitting one would leave a route around the
> API guards.
> * 27-31 add the actual policy enforcement to XML_GetBuffer(), XML_Parse(),
> XML_ParseBuffer(), XML_ParserFree() and XML_ParserReset().
> * 32 adds regression coverage for all five rejected calls.
> Documentation and Changes-file commits from the upstream
> series are dropped because they do not affect the fix or its test
> coverage.
> An explicit XML_Parser cast is added to the regression-test handler
> because handlers.c is also included by handlers_cxx.cpp and compiled as
> C++ in the OE build.
> Upstream pull request:
> https://github.com/libexpat/libexpat/pull/1246
>
> Signed-off-by: Jakub Szczudlo <[email protected]>
Hi Jakub,
We have already rejected a previous attempt to backport this fix due to
the complexity [1].
We have updated our policy for the stable branches [2]:
Patches submitted for a stable branch need to be isolated changes that are
human readable and understandable. Fixes for CVEs or other issues which have
a high complexity, consist of a large number of commits and/or a large
numbers of changed lines are unlikely to be accepted due to the difficulty
they cause with maintainability and scalability.
[1]:
https://lore.kernel.org/openembedded-core/[email protected]/
[2]:
https://lore.kernel.org/yocto-docs/[email protected]/
We're open to discussions of other ways to handle this issue, but we
just don't have the bandwidth to review this patch as-is.
Best regards,
--
Paul Barker
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#244146):
https://lists.openembedded.org/g/openembedded-core/message/244146
Mute This Topic: https://lists.openembedded.org/mt/120905189/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
