A heap-based buffer overflow flaw was found in rpm. When iterReadArchiveNext() processes a symlink entry in an RPM package payload, it reads the target size from the package header as a 64-bit value and allocates a buffer with xmalloc(lsize + 1) at lib/rpmfi.cc:2229. Because there is no upper bound on the header-declared size, a package that sets RPMTAG_LONGFILESIZES to 0xFFFFFFFFFFFFFFFF causes the addition to wrap to zero, so only a 1-byte buffer is allocated. The subsequent rpmcpioRead() call at lib/rpmfi.cc:2230 then copies into that buffer using the payload's independent cpio-header filesize field, which is entirely attacker-controlled and unrelated to the wrapped size, resulting in a heap write of attacker-chosen length and content past the end of the allocation. The archive iterator that reaches this code is entered by the shipped front ends rpm2cpio and rpm2archive (which disable header/signature checks by default) and by rpm -qlvp, so simply parsing or extracting an untrusted .rpm file, without needing a valid signature, triggers the overflow; the same iterator is also entered on the install path. This was confirmed by reproducing the reporter's proof of concept with an AddressSanitizer-instrumented build of rpm at both rpm-6.1.0-release and master, which showed reliable heap-buffer-overflow WRITEs of package-chosen lengths (demonstrated at 256, 4096, and 16248 bytes), each into a 1-byte region allocated at rpmfi.cc:2229, with a negative control (a byte-identical package carrying a truthful LONGFILESIZES value) producing no overflow.