Potential memory leak in sshd [detected by melton]

[Zhenbo Xu]

2012/2/6 Ángel González <keisial at gmail.com>

>  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
>>
>> 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.
>
>
What if line 10511 takes the true branch, and it just "goto out"in line
10514 without releasing allowed.



-- 
Zhenbo Xu