threads / patch / 26673

patchunpack-trees.c: check return value of lstat()

Subject: [PATCH] unpack-trees.c: check return value of lstat()

## tl;dr

5 messages between Mar 6, 2011 and Mar 7, 2011. Diffs are folded; open one to read it.

replies: 4people: 2as markdown or json

Torsten Bögershausen· Mar 6, 2011, 19:13 UTC · lore

Since commit f66caa "do not overwrite files in leading path" at one place lstat() was called but the result was not checked.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
(While I was experimenting with something different, 
this was found by valgrind)
Please review the patch, comments wellcome.
 unpack-trees.c |    7 +++----
 1 files changed, 3 insertions(+), 4 deletions(-)
Show changes to unpack-trees.c +3 −4
diff --git a/unpack-trees.c b/unpack-trees.c
index 1ca41b1..42f7aad 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1374,10 +1374,9 @@ static int verify_absent_1(struct cache_entry *ce,
 		char path[PATH_MAX + 1];
 		memcpy(path, ce->name, len);
 		path[len] = 0;
-		lstat(path, &st);
-
-		return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
-				error_type, o);
+		if (!lstat(path, &st))
+			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
+			                          error_type, o);
 	} else if (!lstat(ce->name, &st))
 		return check_ok_to_remove(ce->name, ce_namelen(ce),
 				ce_to_dtype(ce), ce, &st,

-- 
1.7.4
Matthieu Moy· Mar 6, 2011, 19:29 UTC · re: Torsten Bögershausen · lore

Re: [PATCH] unpack-trees.c: check return value of lstat()

Torsten Bögershausen <tboegi@web.de> writes:
> +		if (!lstat(path, &st))
> +			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
> +			                          error_type, o);
>  	} else if (!lstat(ce->name, &st))
What happens if lstat returns a non-0 value?

Anyway, this seems to have been fixed by a93e53018 (Wed Jan 12 20:28:09 2011, unpack-trees: handle lstat failure for existing file) already.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Torsten Bögershausen· Mar 6, 2011, 19:50 UTC · re: Matthieu Moy · lore

Re: [PATCH] unpack-trees.c: check return value of lstat()

On 06.03.11 20:29, Matthieu Moy wrote:
Show 8 quoted lines
> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> +		if (!lstat(path, &st))
>> +			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
>> +			                          error_type, o);
>>  	} else if (!lstat(ce->name, &st))
> 
> What happens if lstat returns a non-0 value?

The result of "st" is 100% garbage, and should not be passed to anybody. Not checking the return value (error or not) is not a good thing. Developers might be tempted to write unreliable code...

> 
> Anyway, this seems to have been fixed by a93e53018 (Wed Jan 12 20:28:09
> 2011, unpack-trees: handle lstat failure for existing file) already.
> 
Hm,
v1.7.4 says:
commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
Merge: 716958c 9e08273
(so far so good)
My git looks like this:
static int verify_absent_1(struct cache_entry *ce,
				 enum unpack_trees_error_types error_type,
				 struct unpack_trees_options *o)
{
[snip]
	else if (len > 0) {
		char path[PATH_MAX + 1];
		memcpy(path, ce->name, len);
		path[len] = 0;
		lstat(path, &st);
                ^^^^^^^^^^^^^^^^^^
		return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
				error_type, o);

(And I had to correct drizzd@aon.a -> drizzd@aon.at) /Torsten

Matthieu Moy· Mar 6, 2011, 20:57 UTC · re: Torsten Bögershausen · lore

Re: [PATCH] unpack-trees.c: check return value of lstat()

Torsten Bögershausen <tboegi@web.de> writes:
Show 11 quoted lines
> On 06.03.11 20:29, Matthieu Moy wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>> 
>>> +		if (!lstat(path, &st))
>>> +			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
>>> +			                          error_type, o);
>>>  	} else if (!lstat(ce->name, &st))
>> 
>> What happens if lstat returns a non-0 value?
> The result of "st" is 100% garbage, and should not be passed to
> anybody.

With your code, you don't do a return, you'll reach the end of the function without calling return, which is probably the worst thing you could expect.

> v1.7.4 says:
> commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
> Merge: 716958c 9e08273
You've cut the date:
commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
Merge: 716958c 9e08273
Author: Junio C Hamano <gitster@pobox.com>
Date:   Wed Dec 22 14:40:26 2010 -0800
=> no big surprise that you don't see the bugfix from Jan 12th.
>> Anyway, this seems to have been fixed by a93e53018 (Wed Jan 12 20:28:09
>> 2011, unpack-trees: handle lstat failure for existing file) already.
Did you look at the content of this commit?
> (And I had to correct drizzd@aon.a -> drizzd@aon.at)

Yes, because you've mis-spelled it in the first place and I didn't fix it ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Torsten Bögershausen· Mar 7, 2011, 15:59 UTC · re: Matthieu Moy · lore

Re: [PATCH] unpack-trees.c: check return value of lstat()

On 06.03.11 21:57, Matthieu Moy wrote:
Show 41 quoted lines
> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> On 06.03.11 20:29, Matthieu Moy wrote:
>>> Torsten Bögershausen <tboegi@web.de> writes:
>>>
>>>> +		if (!lstat(path, &st))
>>>> +			return check_ok_to_remove(path, len, DT_UNKNOWN, NULL, &st,
>>>> +			                          error_type, o);
>>>>  	} else if (!lstat(ce->name, &st))
>>>
>>> What happens if lstat returns a non-0 value?
>> The result of "st" is 100% garbage, and should not be passed to
>> anybody.
> 
> With your code, you don't do a return, you'll reach the end of the
> function without calling return, which is probably the worst thing you
> could expect.
> 
>> v1.7.4 says:
>> commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
>> Merge: 716958c 9e08273
> 
> You've cut the date:
> 
> commit e39212ab08e8d37dda5d8fd32b54099fe01dbbdb
> Merge: 716958c 9e08273
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Wed Dec 22 14:40:26 2010 -0800
> 
> => no big surprise that you don't see the bugfix from Jan 12th.
> 
>>> Anyway, this seems to have been fixed by a93e53018 (Wed Jan 12 20:28:09
>>> 2011, unpack-trees: handle lstat failure for existing file) already.
> 
> Did you look at the content of this commit?
> 
>> (And I had to correct drizzd@aon.a -> drizzd@aon.at)
> 
> Yes, because you've mis-spelled it in the first place and I didn't fix
> it ;-).
>

Ojojo, While working with the best tracking tool, I lost tracking myself. That's why I missed Jonathans fix and learned today 9e08273 != a93e53018 Thanks for the patience, (and sorry for the noise) /Torsten

← back to recent threads