CVE-2026-92824 in Red Hat
Summary
by MITRE • 10/21/2026
A flaw was found in libmodulemd. In the module stream v2 rpm-map emission path, an inner loop incorrectly uses the count of digest algorithms as its bound instead of the number of checksums in the current digest table. Crafted modulemd v2 metadata with multiple digest types can trigger an out-of-bounds read during YAML serialization, typically causing a crash and resulting in a denial of service.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified within libmodulemd represents a critical logic error in the handling of module stream version two data structures, specifically affecting the rpm-map emission path used for serializing metadata into YAML format. This library serves as a foundational component for managing software modules on Linux distributions such as Fedora and RHEL, where it parses and generates complex dependency trees and package lists. The flaw arises from an incorrect loop bound calculation during the processing of digest information. When constructing the output representation, the code iterates through available checksums but erroneously uses the total count of supported digest algorithm types as the iteration limit rather than the actual number of checksum entries present in the current digest table for a specific package or module component.
This discrepancy creates an out-of-bounds read condition when processing crafted inputs that contain multiple distinct digest types, such as SHA256 and SHA512 hashes simultaneously. Because the loop attempts to access array indices beyond the allocated memory space defined by the actual number of checksums, it reads uninitialized or invalid memory locations. In C-based libraries like libmodulemd, which manage memory manually without automatic garbage collection, accessing out-of-bounds memory typically leads to immediate program instability. The most common manifestation of this flaw is a segmentation fault that causes the application utilizing libmodulemd to crash abruptly. This behavior effectively results in a denial of service condition for any system or tool relying on the library for module metadata processing at that specific point in execution.
From an operational perspective, the impact depends heavily on how libmodulemd is integrated into downstream applications. If used within command-line tools like dnf or rpm during package installation or repository synchronization, this vulnerability could allow a local attacker to crash these services by providing maliciously crafted module metadata files. While remote exploitation via network-facing services is less likely unless specific web-based interfaces are involved that parse untrusted module streams directly, the integrity of the build and deployment pipelines remains at risk. An adversary with the ability to inject or modify repository metadata could trigger this flaw in automated systems, disrupting continuous integration workflows or causing service outages for package managers processing affected repositories.
This vulnerability aligns closely with CWE-125, which describes an Out-of-Bounds Read scenario where software reads data past the end of a buffer or array. It also relates to CWE-787, as improper bounds checking is often categorized under insufficient validation of boundary conditions in input handling routines. In terms of adversary tactics, this flaw could be leveraged within ATT&CK technique T1496, Resource Hijacking, specifically for denial-of-service purposes by exhausting system resources through repeated crashes or service interruptions. It does not currently appear to facilitate arbitrary code execution due to the nature of a read-only overflow in this context, but it significantly undermines the reliability and availability of module management tools.
Mitigation strategies should focus on immediate patching of libmodulemd to versions that correct the loop bound logic to use the actual checksum count rather than the digest algorithm count. Developers integrating this library must ensure they are using patched releases across all environments where module metadata is processed. For system administrators, monitoring for unexpected crashes in package management tools and verifying repository integrity can help detect potential exploitation attempts. Additionally, implementing strict input validation at higher-level application layers to sanitize or limit the complexity of digest structures before passing them to libmodulemd can provide an additional layer of defense against malformed inputs designed to trigger this out-of-bounds read condition.