CVE-2026-103242: Rpm: heap-based buffer overflow write in hex2binv() via a mistyped rpmtag_filesignatures header tag
A heap-based buffer overflow flaw was found in rpm. RPMTAGFILESIGNATURES in a crafted, unsigned RPM package's main header is declared with the wrong header type, causing hex2binv() to allocate a one-byte buffer and then write the tag's attacker-controlled, hex-decoded content — of attacker-chosen length — past the end of that allocation. This is reachable via rpm2cpio, rpm2archive, and rpm -qlvp on an untrusted package.
Other sources
A heap-based buffer overflow write was found in RPM's hex2binv() function (lib/rpmfi.cc). In a crafted, unsigned RPM v4 package, the RPMTAGFILESIGNATURES tag in the main header is declared with type RPMI18NSTRINGTYPE (9) instead of its intended RPMSTRINGARRAYTYPE (8). This mismatch causes headerGet() to route the tag through copyI18NEntry(), which sets the tag's count and data but never sets its size field. hex2binv() sizes its output buffer from that (unset, and therefore zero) size, allocating only one byte, while its decode loop then writes half the length of the attacker-controlled hex string into that one-byte buffer -- an overflow of arbitrary, attacker-chosen length past the allocation.
The flaw is reachable by any command or library caller that populates rpmfi/rpmfiles data from an untrusted package's file signatures, such as rpm -qlvp, rpm2cpio, or rpm2archive. No package signature is required, since these tools do not validate package signatures by default. The issue was confirmed against the shipped rpm binary on Fedora Linux 44 (rpm-6.0.2): Valgrind reports an invalid one-byte write immediately past a one-byte heap allocation inside rpmfilesNew() (the inlined caller of hex2binv()), and a larger crafted payload reliably crashes the process with SIGSEGV.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Which workflows can process a malicious package and trigger the overflow?
The issue is reachable when an untrusted RPM package is processed with rpm2cpio, rpm2archive, or rpm -qlvp. It can also affect library callers that populate file-signature information from the package header.
What does an attacker need to provide for exploitation?
An attacker needs to convince a user or local process to handle a crafted, unsigned RPM v4 package. The package's main header must contain RPMTAG_FILESIGNATURES declared as RPM_I18NSTRING_TYPE rather than RPM_STRING_ARRAY_TYPE, with attacker-controlled hexadecimal content.
Is installing the package required to be affected?
No. The vulnerable parsing path is reached by the listed package-inspection and extraction commands when they process the untrusted package; the description does not require installation.