REDHAT-BUG-2543866: Buffer Overflow
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.
Affected Software
Event History
Frequently Asked Questions
Which workflows are exposed to this issue?
Any command or library caller that populates rpmfi or rpmfiles data from an untrusted package's file signatures is exposed. Examples named in the report include rpm -qlvp, rpm2cpio, and rpm2archive.
Does an attacker need a valid package signature?
No. The crafted RPM v4 package can be unsigned because the affected tools do not validate package signatures by default.
What must be present in a malicious package to trigger the overflow?
The package must use a crafted RPMTAG_FILESIGNATURES tag in the main header, declaring it as RPM_I18NSTRING_TYPE (9) rather than RPM_STRING_ARRAY_TYPE (8). The attacker-controlled hex string then drives writes beyond a one-byte heap allocation.
Is there evidence that a shipped distribution build is affected?
The issue was confirmed against the shipped RPM binary on Fedora Linux 44, using rpm-6.0.2. Valgrind reported an invalid write immediately after a one-byte heap allocation in rpmfilesNew().