Potential memory leak in sshd [detected by melton]

Ángel González keisial at gmail.com
Mon Feb 6 19:58:20 EST 2012


On 06/02/12 03:30, Zhenbo Xu wrote:
>
>     The 10th report is another false positive:
>     Logic error 	Memory leak 	auth-options.i 	10587 	28 	View Report
>     <http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath>
>
>
>     http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath
>     <http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-mVEeJj.html#EndPath>
>
>     Melton complains that in line 10587 the memory of data wasn't
>     released, but there's a call to buffer_free(&data);
>     in line 10585.
>
>
> What melton complains is the heap object returned
> by buffer_get_cstring_ret
> <http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/linked_files/linked-TOML0p.html#Path29_2> wasn't
> released.
You are right. I missed that it was about allowed.
However, Melton is doing:

> switch (addr_match_cidr_list(remote_ip,
>
> 	
> 11
> 	Control jumps to 'case 1:' at line 10525
>
> 10524 	allowed)) {
> 10525 	case 1:
> 10526 	
> 10527 	xfree(allowed);
> 10528 	break;
>
> 	
> 12
> 	Execution continues on line 10548
>
Where it is freed (and add_match_cidr_list can only return -1, 0 or 1 so
all cases are covered).

Then it seems to do another loop where buffer_get_cstring_ret
<http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/linked_files/linked-TOML0p.html#Path29_2>
returns NULL, so nothing was allocated.

I still don't see the leak.




More information about the openssh-unix-dev mailing list