cache: truncate lock file before filling

lockslot() opens the lock file with ORDWR|OCREAT but without
OTRUNC. If a previous cgit process was killed between lockslot() and
unlockslot() (e.g. by a CGI timeout or OOM), the stale lock file
remains on disk with the old content, and the kernel releases the fcntl
lock.
The next process to claim the same cache slot then opens this stale lock
file, acquires the fcntl lock, writes its key and generated content on
top of the old bytes. If the new response is shorter than what was
previously in the file, trailing bytes from the old response survive
beyond the end of the new content. fstat() in fillslot() reports the
total file size (including the stale tail), and printslot() faithfully
sends all of it – producing a response that is the correct page
followed by a fragment of whatever previously occupied that lock file.
Fix this by truncating the lock file after acquiring the lock and before
writing the new key.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

1 files changed, 2 insertions, 0 deletions

diff --git a/cache.c b/cache.c
index 1c843ba..e70af13 100644
--- a/cache.c
+++ b/cache.c
@@ -185,6 +185,8 @@ static int lock_slot(struct cache_slot *slot)
 		slot->lock_fd = -1;
 		return saved_errno;
 	}
+	if (ftruncate(slot->lock_fd, 0) < 0)
+		return errno;
 	if (xwrite(slot->lock_fd, slot->key, slot->keylen + 1) < 0)
 		return errno;
 	return 0;