On 2024-12-23 14:27, exploit dev wrote:
In decode_header(), assign_string_n() takes input from header.uname as value and also as size_t. [image: image.png]
I didn't look at the images, for what I hope are obvious security reasons. If they contain important info please resend as text. (In general it's better to send text for this kind of email.)
If value and n are both controlled, the "l" variable is prone to overflowing inside the xmalloc(l+1) which will under-allocate p, and over-copy value into it.
I don't see how that can happen on any practical porting target of GNU Tar. The last arg of assign_string_n is always small, so l + 1 cannot overflow.
