CVE-2003-0695

An attacker can trigger these buffer management errors by sending crafted SSH protocol messages that cause the internal buffer or channel array to be resized. The advisory states it is uncertain whether these errors are exploitable, but they could lead to denial of service or arbitrary code execution. The preconditions are network access to an OpenSSH server (sshd) running a version prior to 3.7.1. No authentication is required to reach the vulnerable code paths.

The bugs reside in `buffer.c` (functions `buffer_init`, `buffer_free`, and `buffer_append_space`) and `channels.c` (the channel array expansion logic in `channel_new`). In `buffer_init`, the allocation size was stored before the buffer was allocated, leaving a window where `buffer->alloc` could be stale. In `buffer_free`, the code unconditionally accessed `buffer->alloc` without checking if it was valid. In `buffer_append_space`, the allocation size was updated after `xrealloc`, so a failure could leave `buffer->alloc` inconsistent. In `channels.c`, `channels_alloc` was incremented before `xrealloc`, causing the reallocation to use the wrong (already-incremented) size.

The patch reorders operations in `buffer_init` so that `buffer->alloc` is set only after `xmalloc` succeeds, preventing a stale allocation size. In `buffer_free`, a guard (`if (buffer->alloc > 0)`) prevents calling `memset` and `xfree` on an uninitialized or zero-size buffer. In `buffer_append_space`, the new allocation size is computed into a local variable `newlen` and assigned to `buffer->alloc` only after `xrealloc` returns, ensuring consistency. In `channels.c`, the `xrealloc` call now uses `(channels_alloc + 10) * sizeof(Channel *)` before incrementing `channels_alloc`, so the correct size is passed to the reallocation.