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