Hi, I was considering to document the functions of ar.c when I noticed a possible issue in dpkg. It seems to me that dpkg_ar_member_get_size may (silently) truncate a "large file" when off_t is 32 bits. But I admit being uncertain here as I had difficulties finding a normative specification of the ar format.
As far as I can tell, off_t is signed[1] and can be 32 bits[2]. According to the wikipedia[3] and <ar.h>, the size of an ar member is specified as (up to) 10 (ASCII encoded) digits. The question is whether or not all 10 chars can be digits or one of them will always be a space (or other terminator). I admit having difficulties finding a normative answer. I did find [4], which suggests the file size limit for a given member is 4 GB (implying that all 10 chars may be digits). In the case that all 10 digits are usable, then a 32 bit off_t can overflow when parsing the file size. The issue is that dpkg_ar_member_get_size does not check for this case and will cause the "size" to overflow. In fact, it may even "flow back into positive" making it impossible for the caller to discover the that an overflow occured. ~Niels [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/systypes.h.html [2] http://pubs.opengroup.org/onlinepubs/7908799/xsh/unistd.h.html and http://www.gnu.org/software/libc/manual/html_node/File-Size.html [3] http://en.wikipedia.org/wiki/Ar_%28Unix%29 [4] http://docs.oracle.com/cd/E23824_01/html/821-1464/ar-3head.html -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
