CVE-2026-82327 in Red Hat
Summary
by MITRE • 08/28/2026
A flaw was found in libsolv, a dependency-resolution library used by RPM-based package managers such as dnf and zypper to work with .solv repository cache files. When libsolv rewrites a .solv cache file, it reads directory-id values from the file's compressed filelist data without validating that they fall within the expected range. A corrupted or specially crafted .solv cache file (for example, one left in a torn state after an unclean system shutdown) can cause an out-of-bounds memory write when a tool such as dnf, yum, or zypper next processes it. Successful exploitation is expected to result in a crash of the affected tool (denial of service); it is not expected to allow arbitrary code execution because the out-of-bounds write always stores a fixed, non-attacker-controlled value.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified within libsolv represents a critical integrity failure in how dependency-resolution libraries handle repository cache data on RPM-based Linux distributions. Libsolv serves as the foundational engine for package managers such as dnf and zypper, responsible for parsing complex metadata to resolve software dependencies efficiently. The specific flaw resides in the mechanism used when these tools rewrite or update .solv cache files. During this process, the library extracts directory-id values from compressed filelist data embedded within the cache structure. Crucially, the implementation fails to perform adequate bounds checking on these extracted identifiers before using them as indices for memory operations. This lack of validation creates a scenario where malformed input can directly influence internal pointer arithmetic or array indexing logic without proper safeguards against out-of-bounds access.
The operational impact of this flaw is primarily centered around system stability and availability rather than direct code execution. When an attacker, or in many cases simply the environment itself through corruption, provides a specially crafted .solv cache file, the application attempts to write data at a memory location determined by the invalid directory-id value. Because the out-of-bounds write consistently stores a fixed, non-attacker-controlled value rather than arbitrary user input, the likelihood of achieving remote code execution is negligible. Instead, the immediate consequence is a segmentation fault or similar crash within the package manager process. This results in a denial of service condition where users are unable to install, update, or remove software packages until the cache is regenerated or repaired. Such failures can disrupt automated system maintenance scripts and hinder administrative workflows that rely on consistent package management operations.
From a threat modeling perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write, as it involves writing data to a memory location outside the intended buffer boundary due to insufficient validation of input values derived from external sources. The attack vector is classified under ATT&CK technique T1496: Resource Hijacking or more specifically relates to availability impacts through resource exhaustion via crashes, though in this context, it is best categorized as an integrity violation leading to denial of service. While the initial trigger might be accidental due to file system corruption during unclean shutdowns, a malicious actor could potentially distribute poisoned repository metadata containing crafted .solv files to induce these crashes across multiple systems within an enterprise environment. This makes it a potential vector for targeted disruption rather than compromise.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The primary defense is the application of vendor-provided patches that update libsolv to include strict range validation for directory-id values before they are used in memory operations. System administrators should ensure their package managers are updated to versions containing this fix. In environments where patching cannot be immediately applied, monitoring logs for frequent crashes in dnf or zypper processes can serve as an early warning indicator of cache corruption or potential exploitation attempts. Furthermore, implementing file system integrity checks and ensuring clean shutdown procedures can reduce the risk of accidental cache corruption that might otherwise trigger this vulnerability unintentionally. Regularly regenerating repository caches after major updates also helps maintain data consistency and reduces exposure to stale or corrupted metadata structures.