[fedfs-utils] [PATCH 2/8] fedfsd: don't return freed memory through **pathname parameter, ...

Chuck Lever chuck.lever at oracle.com
Wed Nov 30 13:31:57 PST 2011


On Nov 30, 2011, at 4:20 PM, Jim Meyering wrote:

> Chuck Lever wrote:
> 
>> On Nov 30, 2011, at 3:51 PM, Jim Meyering wrote:
>> 
>>> From: Jim Meyering <meyering at redhat.com>
>>> 
>>> even though upon error it will not be used.
>>> * src/fedfsd/svc.c (fedfsd_pathwalk): On an error path, don't
>>> set *pathname at all, and certainly not to a just-freed pointer.
>>> 
>>> mount avoid one-byte heap-write overrun
>>> ---
>>> src/fedfsd/svc.c |    1 -
>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>> 
>>> diff --git a/src/fedfsd/svc.c b/src/fedfsd/svc.c
>>> index 132be70..3509082 100644
>>> --- a/src/fedfsd/svc.c
>>> +++ b/src/fedfsd/svc.c
>>> @@ -318,7 +318,6 @@ fedfsd_pathwalk(const FedFsPathName fpath, char **pathname)
>>> 		retval = fedfsd_pathwalk_check_term(result);
>>> 		if (retval != FEDFS_OK)
>>> 			free(result);
>>> -		*pathname = result;
>> 
>> if retval is FEDFS_OK, we want to preserve the result.
>> So the existing code is incorrect, but this fix is also wrong.  How about
> 
> Oh.  How embarrassing.
> 
>> 	if (retval != FEDFS_OK) {
>> 		free(result);
>> 		return retval;
>> 	}
>> 	*pathname = result;
>> 	return FEDFS_OK;
>> 
>>> 		return retval;
>>> 	}
> 
> How about this instead?
> This way there's a single return point and no duplicated FEDFS_OK:
> 
> 	if (fpath.FedFsPathName_len == 0) {
> 		xlog(D_CALL, "%s: Zero-component pathname", __func__);
> 		strcat(result, "/");
> 		retval = fedfsd_pathwalk_check_term(result);
> 		if (retval == FEDFS_OK)
> 			*pathname = result;
> 		else
> 			free(result);
> 		return retval;
> 	}

The pattern is generally:

	if (error)
		do exception handling
	do the non-error case

I call this bfields-normal form, after bfields at redhat.com, as he finds this logic easier to read than other ways to express it.  I don't typically use the "else" form elsewhere in this code.

The "return FEDFS_OK" nails the return code instead of letting it leak through.  That tends to be more immune to changes in the code around it.  The small code duplication doesn't bug me.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com







More information about the fedfs-utils-devel mailing list