From: Jeff King <peff@peff.net>
To: Thomas Jarosch <thomas.jarosch@intra2net.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
Johannes Sixt <j.sixt@viscovery.net>,
git@vger.kernel.org
Subject: Re: [PATCH] setup_revisions(): do not access outside argv
Date: Fri, 22 May 2009 03:56:20 -0400 [thread overview]
Message-ID: <20090522075620.GC1409@coredump.intra.peff.net> (raw)
In-Reply-To: <4A159720.3020103@intra2net.com>
On Thu, May 21, 2009 at 08:02:08PM +0200, Thomas Jarosch wrote:
> Speaking of that, there is also one piece of code in diff.c that doesn't do
> NULL-termination after a readlink() call (which never NULL-terminates).
> The current use is 100% fine, though the same maintenance
> argument might apply here, too. Wondering why the buffer
> is allocated as PATH_MAX +1. Hmm.
Yeah, it is fine because it just passes the result to prep_temp_blob,
which respects the length. I don't know if it is worth making it more
safe (arguably it should just be using strbuf_readlink anyway, but that
does introduce an extra malloc).
I grepped and every other call to readlink is already doing this (and
most just use strbuf_readlink anyway).
-- >8 --
Subject: NUL-terminate readlink results
readlink does not terminate its result, but instead returns the length
of the path. This is not an actual bugfix, as the value is currently
only used with its length. However, terminating the string helps make it
safer for future uses.
Signed-off-by: Jeff King <peff@peff.net>
---
This does feel a bit like code churn, but I'm not sure it is any
different than the NULL-terminate all argv proposal.
diff --git a/diff.c b/diff.c
index f06876b..b398360 100644
--- a/diff.c
+++ b/diff.c
@@ -2021,6 +2021,7 @@ static struct diff_tempfile *prepare_temp_file(const char *name,
die("readlink(%s)", name);
if (ret == sizeof(buf))
die("symlink too long: %s", name);
+ buf[ret] = '\0';
prep_temp_blob(name, temp, buf, ret,
(one->sha1_valid ?
one->sha1 : null_sha1),
next prev parent reply other threads:[~2009-05-22 7:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 8:08 [PATCH] setup_revisions(): do not access outside argv Nguyễn Thái Ngọc Duy
2009-05-20 8:15 ` Johannes Sixt
2009-05-20 8:23 ` Nguyen Thai Ngoc Duy
2009-05-21 1:58 ` Junio C Hamano
2009-05-21 2:38 ` Miles Bader
2009-05-21 2:41 ` Nguyen Thai Ngoc Duy
2009-05-21 4:18 ` Jeff King
2009-05-21 18:02 ` Thomas Jarosch
2009-05-22 7:56 ` Jeff King [this message]
2009-05-22 8:02 ` Jeff King
2009-05-22 14:23 ` Thomas Jarosch
2009-05-22 15:33 ` Brandon Casey
2009-05-22 15:34 ` Jeff King
2009-05-25 10:46 ` [PATCH] convert bare readlink to strbuf_readlink Jeff King
2009-05-25 22:23 ` Junio C Hamano
[not found] ` <20090602195605.6117@nanako3.lavabit.com>
2009-06-02 13:57 ` [PATCH] setup_revisions(): do not access outside argv Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090522075620.GC1409@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=j.sixt@viscovery.net \
--cc=pclouds@gmail.com \
--cc=thomas.jarosch@intra2net.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).