Repository navigation
Conversation
A modulemd document with "xmd" element having 2^16 nested single-character mapping elements, occupying 327860 bytes, causes modulemd-validator to exhaust all heap memory (tens of gigabytes) when duplicating subdocuments in modulemd_yaml_parse_document_type_internal(). This patch adds a "recursion_limit" build-time option defining a maximal depth of acceptable YAML documents. Default is 64. The only recursive structure in the modulemd documents is "xmd" which has unspecified content. Thus this patch adds tests exhibiting modulemd_yaml_parse_document_type() on an acceptable document and on an oversized document. modulemd_yaml_parse_document_type() is common to all public parsing functions and calls the affected modulemd_yaml_parse_document_type_internal() function. This flaw was confirmed in current 2.15.3 version and back to 1.4.0 version. Earlier versions might be affected as well. Acknowledgement: Aisle Research Resolves: CVE-2026-92822
This patch is not needed per se because all code paths leading to mmd_parse_xmd() get the YAML XMD tree from a subdocument obtained with modulemd_yaml_parse_document_type() which is already protected by the recursion limit. We apply this patch as a hardening for possible future code paths. As a side effect, this patch fixes propagating errors from mmd_variant_from_mapping() in mmd_parse_xmd(). Acknowledgement: Aisle Research Resolves: CVE-2026-92822
|
Collaborator
Author
|
The "duplicated code" reported by SonarCloud is false. It's needed to reach the point were we can exhibit the tested function. One could hide parts of the code behind macros, but I prefer the code the the same interface as provided by the library instead of inventing test-only helpers and making the code more obfuscated. Especially when glib's assert macros report line numbers as the only identifier of which test failed. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A modulemd document with "xmd" element having 2^16 nested
single-character mapping elements, occupying 327860 bytes, causes
modulemd-validator to exhaust all heap memory (tens of gigabytes) when
duplicating subdocuments in modulemd_yaml_parse_document_type_internal().
This patch adds a "recursion_limit" build-time option defining a maximal
depth of acceptable YAML documents. Default is 64.
The only recursive structure in the modulemd documents is "xmd" which
has unspecified content. Thus this patch adds tests exhibiting
modulemd_yaml_parse_document_type() on an acceptable document and
on an oversized document. modulemd_yaml_parse_document_type() is
common to all public parsing functions and calls the affected
modulemd_yaml_parse_document_type_internal() function.
This flaw was confirmed in current 2.15.3 version and back to 1.4.0
version. Earlier versions might be affected as well.
Acknowledgement: Aisle Research
Resolves: CVE-2026-92822