Hello, tarnamecpy receives the size of a destination field and copies at most size - 1 bytes, but it currently writes the terminator to buf[size]. That is one byte past the field: the uname call reaches gname[0], and the gname call reaches devmajor[0].
The containing tar record is currently zero-initialized and the adjacent fields are subsequently written, which masks an observable corruption in the existing callers. I am therefore not claiming an exploitable impact; this patch fixes the bounded out-of-field write introduced by commit e8931bebb9e159a67db64ac1ac86314566ad24d8. The patch writes the terminator to the last valid byte. I tested it on macOS arm64 with Clang ASan/UBSan: all 16 runnable tests passed (one platform-specific test skipped), and a fresh USTAR archive was readable by both the patched cpio and the system tar. Regards, Darren Carreras
From b9ebf0062bb4b3910a39ebce3998faab6af7b648 Mon Sep 17 00:00:00 2001 From: Darren Carreras <[email protected]> Date: Wed, 5 Aug 2026 13:01:27 -0400 Subject: [PATCH] tar: fix off-by-one write in tarnamecpy * src/tar.c (tarnamecpy): Write the string terminator within the destination buffer. --- src/tar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tar.c b/src/tar.c index 8f4ebb1..ff7af7c 100644 --- a/src/tar.c +++ b/src/tar.c @@ -131,7 +131,7 @@ static void tarnamecpy (char *buf, char const *name, size_t size) { strncpy (buf, name, size-1); - buf[size] = 0; + buf[size-1] = 0; } /* Write out header FILE_HDR, including the file name, to file -- 2.50.1 (Apple Git-155)
