Re: [CHECKER] 32 Memory Leaks on Error Paths

[Neil Brown]

On Monday September 15, dychen@xxxxxxxxxxxx wrote:
> Hi All,
> 
> I'm with the Stanford Meta-level Compilation research group, and I
> have a set of memory leaks on error paths for the 2.6.0-test5 kernel.
> (I also have error reports for 2.4.18 and a couple other kernels if
> anyone is interested).
> 
> There may be one or more "GOTO -->" markers showing the different
> paths of execution that can occur between where the memory is
> allocated and where the function returns.
> 
> My checker identifies error paths with a learning algorithm on
> features surrounding goto and return statements.  I'd greatly
> appreciate any comments or confirmation on these bugs.
> 
> Thanks!

The nfsd/nfsctl.c one isn't actually a bug (though I had to think
about it a bit to be sure).

One of the "... DETELED 4 lines ..." is

		file->private_data = ar;

which takes a copy of "ar" into a structure that has a lifetime
greater than the function.
So when the "return -EFAULT" happends (at END -->), at is stored in
file->private_data, and a subsequent call to TA_release will free that
memory.

NeilBrown


> 
> [FILE:  2.6.0-test5/fs/nfsd/nfsctl.c]
> [FUNC:  TA_write]
> [LINES: 105-120]
> [VAR:   ar]
>  100:	if (file->private_data) 
>  101:		return -EINVAL; /* only one write allowed per open */
>  102:	if (size > PAGE_SIZE - sizeof(struct argresp))
>  103:		return -EFBIG;
>  104:
> START -->
>  105:	ar = kmalloc(PAGE_SIZE, GFP_KERNEL);
>  106:	if (!ar)
>  107:		return -ENOMEM;
>  108:	ar->size = 0;
>  109:	down(&file->f_dentry->d_inode->i_sem);
>  110:	if (file->private_data)
>         ... DELETED 4 lines ...
>  115:	if (rv) {
>  116:		kfree(ar);
>  117:		return rv;
>  118:	}
>  119:	if (copy_from_user(ar->data, buf, size))
> END -->
>  120:		return -EFAULT;
>  121:	
>  122:	rv =  write_op[ino](file, ar->data, size);
>  123:	if (rv>0) {
>  124:		ar->size = rv;
>  125:		rv = size;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/