Report
While auditing GNU tar's archive header parser, I inspected the GNUTYPE_LONGNAME/GNUTYPE_LONGLINK handling in src/list.c. The parser allocates a buffer based on the declared size, then copies each subsequent data block into it and terminates with NUL. The code assumes the archive actually contains the full payload and continues even when find_next_block() returns NULL, leaving a partially populated long-name buffer that is later consumed as a pathname/linkname. This is a fragile trust boundary around archive metadata and block sequencing.
90890841-79c4-499e-ac4f-cd08aa1759b6
While auditing GNU tar's archive header parser, I inspected the GNUTYPE_LONGNAME/GNUTYPE_LONGLINK handling in src/list.c. The parser allocates a buffer based on the declared size, then copies each subsequent data block into it and terminates with NUL. The code assumes the archive actually contains the full payload and continues even when find_next_block() returns NULL, leaving a partially populated long-name buffer that is later consumed as a pathname/linkname. This is a fragile trust boundary around archive metadata and block sequencing.