mosh-server aborts in Framebuffer::resize when client sends initial winsize 0x0

Hi,

I found a reproducible crash in mosh-server when the client side starts with a PTY reporting terminal size 0 0.

Environment:

• Server: Ubuntu 24.04.4 LTS
• Packaged mosh: 1.4.0-1ubuntu3
• Also reproduced on upstream master: decd9b7
• Built from source with default configure options
• Architecture: x86_64

Observed behavior: mosh-server starts normally, receives the first UDP packet from the client, then aborts with SIGABRT.

Backtrace:

#4 abort()
#5 __assert_fail_base(
    assertion="s_width > 0",
    file="terminalframebuffer.cc",
    line=408,
    function="Terminal::Framebuffer::resize(int, int)"
)

On the Ubuntu package the same assertion is at approximately line 403.

The failing function is:

void Framebuffer::resize( int s_width, int s_height )
{
  assert( s_width > 0 );
  assert( s_height > 0 );
  ...
}

Reproducer:

script -q /dev/null mosh --server=/path/to/mosh-server host

In my environment, script -q /dev/null creates a PTY whose stty size reports 0 0. This causes the client to send an initial resize/state with width or height equal to zero. The server then aborts on the assertion after receiving the first UDP packet.

Expected behavior: mosh-server should not abort when it receives an invalid terminal resize such as 0x0. It should either ignore the invalid resize, clamp it to a safe default, or wait for the next valid resize from the client.

Local patch tested: I tested a minimal local change that ignores invalid resize requests:

void Framebuffer::resize( int s_width, int s_height )
{
  if ( s_width <= 0 || s_height <= 0 ) {
    return;
  }

  ...
}

Result:

The crash disappears. mosh-server no longer produces a coredump. The same reproducer no longer kills the server. make check passes. A normal control test with valid terminal size works and produces bidirectional UDP traffic.