Potential memory leak in sshd [detected by melton]

[Zhenbo Xu]

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

>  On 04/02/12 02:55, Zhenbo Xu wrote:
>
> I also applied melton(http://lcs.ios.ac.cn/~xuzb/melton.html)
>
> to detect the potential bugs in sshd (openssh-5.9p1).
>
>
> The url below is the index of bug reports that are checked as real
> bugs manually.
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/index.html
>
>
> Shall we fix these bugs? Or just let them go since they are not so serious?
> Hope for your replies!
>
>
> The second leak
>
>   Logic error Memory leak session.i 13193 13 View Report<http://lcs.ios.ac.cn/%7Exuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath>
>
>
> http://lcs.ios.ac.cn/~xuzb/bugsfound/memleak/openssh-5.9p1/realbugs/sshd/report-zSMfqI.html#EndPath
>
> is a false positive.
>
> The only way to exit the infinite loop is the return of line 13267.
> And line 13266 calls session_close(), which frees s->auth_data in line
> 14994.
> (granted, it's tricky to follow...)
>

This report may not be so clear.
The leak occurs at the second loop iteration when the "type =
packet_read()" is equal to case 34 (line 13192) twice.
At the first iteration, s->auth_proto gets a heap buffer but is not freed.
And at the second iteration, s->auth_proto is reassigned,
which means the heap buffer allocated at the first iteration leaks.


> The analysis seem to have stopped in line 13193, after step 14.
>
> As a suggestion, I recommend you to make the messages "Execution continues
> on line 12345"
> links to line 12345.
> Also, going to the opening brace from the closing one would be useful when
> dealing with big blocks.
>
>
Thank you for your suggestion and your detail replies!



-- 
Zhenbo Xu