Re: [PATCH] Prevent buffer overflows when path is too long

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Antoine Pelisse <apelisse@xxxxxxxxx> writes:

> Some buffers created with PATH_MAX length are not checked when being
> written, and can overflow if PATH_MAX is not big enough to hold the
> path.

Perhaps it is time to update all of them to use strbuf?  The callers
of prefix_filename() aren't that many, and all of them are prepared
to stash the returned value away when they keep it longer term, so
they would not notice if we used "static struct strbuf path" and
gave back "path.buf" (without strbuf_detach() on it).  The buffer
used in clear_ce_flags() and passed to clear_ce_flags_{1,dir} are
not seen outside the callchain, and can safely become strbuf, I
think.

>  abspath.c        | 10 ++++++++--
>  diffcore-order.c | 14 +++++++++-----
>  unpack-trees.c   |  2 ++
>  3 files changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/abspath.c b/abspath.c
> index e390994..29a5f9d 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -216,11 +216,16 @@ const char *absolute_path(const char *path)
>  const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
>  {
>  	static char path[PATH_MAX];
> +
> +	if (pfx_len >= PATH_MAX)
> +		die("Too long prefix path: %s", pfx);

I do not think this is needed, and will reject a valid input that
used to be accepted (e.g. arg is absolute so pfx does not matter).

>  #ifndef GIT_WINDOWS_NATIVE
>  	if (!pfx_len || is_absolute_path(arg))
>  		return arg;
>  	memcpy(path, pfx, pfx_len);
> -	strcpy(path + pfx_len, arg);
> +	if (strlcpy(path + pfx_len, arg, PATH_MAX - pfx_len) > PATH_MAX)
> +		die("Too long path: %s", path);

Rather, have that "too long a prefix?" check before that memcpy().

>  #else
>  	char *p;
>  	/* don't add prefix to absolute paths, but still replace '\' by '/' */
> @@ -228,7 +233,8 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
>  		pfx_len = 0;
>  	else if (pfx_len)
>  		memcpy(path, pfx, pfx_len);

... and around here.

> -	strcpy(path + pfx_len, arg);
> +	if (strlcpy(path + pfx_len, arg, PATH_MAX - pfx_len) > PATH_MAX)
> +		die("Too long path: %s", path);
>  	for (p = path + pfx_len; *p; p++)
>  		if (*p == '\\')
>  			*p = '/';

The above is curious. Unless we are doing the short-cut for "no
prefix so we can just return arg" codepath, we know that the
resulting length is always pfx_len + strlen(arg), no?

> diff --git a/diffcore-order.c b/diffcore-order.c
> index 23e9385..87193f8 100644
> --- a/diffcore-order.c
> +++ b/diffcore-order.c
> @@ -73,20 +73,24 @@ struct pair_order {
>  static int match_order(const char *path)
>  {
>  	int i;
> -	char p[PATH_MAX];
> +	struct strbuf p = STRBUF_INIT;
>  
>  	for (i = 0; i < order_cnt; i++) {
> -		strcpy(p, path);
> -		while (p[0]) {
> +		strbuf_reset(&p);
> +		strbuf_addstr(&p, path);
> +		while (p.buf[0]) {
>  			char *cp;
> -			if (!fnmatch(order[i], p, 0))
> +			if (!fnmatch(order[i], p.buf, 0)) {
> +				strbuf_release(&p);
>  				return i;
> -			cp = strrchr(p, '/');
> +			}
> +			cp = strrchr(p.buf, '/');
>  			if (!cp)
>  				break;
>  			*cp = 0;
>  		}
>  	}
> +	strbuf_release(&p);
>  	return order_cnt;
>  }
>  
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 35cb05e..f93565b 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -918,6 +918,8 @@ static int clear_ce_flags_1(struct cache_entry **cache, int nr,
>  			int processed;
>  
>  			len = slash - name;
> +			if (len + prefix_len >= PATH_MAX)
> +				die("Too long path: %s", prefix);
>  			memcpy(prefix + prefix_len, name, len);
>  
>  			/*
> -- 
> 1.8.5.rc3.1.ga0b6b91
>
> -- 
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]