CVE-2003-0693

An attacker can send crafted SSH protocol messages that cause the internal buffer to be reallocated. If the reallocation fails (e.g., due to memory pressure), the buffer management error in `buffer_append_space` or `channel_new` leaves `buffer->alloc` or `channels_alloc` inconsistent with the actual allocated memory. A subsequent call to `buffer_free` then passes an incorrect size to `memset` and `xfree`, corrupting the heap. This can potentially be leveraged to execute arbitrary code on the sshd process [ref_id=1].

The vulnerability resides in `buffer.c` (functions `buffer_init`, `buffer_free`, `buffer_append_space`) and `channels.c` (function `channel_new`). In `buffer_init`, `buffer->alloc` was set before `buffer->buf` was allocated, so if `xmalloc` failed the freed size would be wrong. In `buffer_append_space`, the allocation size was updated before calling `xrealloc`, so a failed realloc could leave `buffer->alloc` inconsistent with the actual buffer size. In `channel_new`, `channels_alloc` was incremented before `xrealloc`, so a failed realloc would leave the count inconsistent with the array size [ref_id=1].

The patch reorders operations in `buffer_init` so that `buffer->alloc` is set to 0 before `xmalloc`, then updated to the actual allocation size only after success. In `buffer_append_space`, a temporary variable `newlen` is computed first; only after `xrealloc` succeeds is `buffer->alloc` updated. In `buffer_free`, a guard checks `buffer->alloc > 0` before using it. In `channel_new`, `channels_alloc` is incremented only after `xrealloc` succeeds. These changes ensure that allocation size metadata always matches the actual buffer size, preventing incorrect `memset`/`xfree` calls that could corrupt the heap [ref_id=1].