GHSA-2r2c-cx56-8933

### Summary The JLine3 Telnet server (`remote-telnet` module) does not apply an upper bound to terminal dimensions received via the Telnet NAWS (Negotiate About Window Size) option. An unauthenticated remote attacker can send a NAWS subnegotiation advertising a 65535×65535 terminal and repeatedly alternate values to trigger continuous, expensive rendering work on the server, causing CPU exhaustion and denial of service. ### Details `TelnetIO.handleNAWS()` (TelnetIO.java:856-879) reads the client-supplied width and height as 16-bit unsigned integers and passes them to `setTerminalGeometry()`: ```java // TelnetIO.java:869-875 private void setTerminalGeometry(int columns, int rows) { if (columns < SMALLEST_BELIEVABLE_WIDTH) columns = DEFAULT_WIDTH; // lower bound only if (rows < SMALLEST_BELIEVABLE_HEIGHT) rows = DEFAULT_HEIGHT; connectionData.setTerminalGeometry(columns, rows); connection.processConnectionEvent( new ConnectionEvent(connection, ConnectionEvent.Type.CONNECTION_TERMINAL_GEOMETRY_CHANGED)); } ``` Only a *lower* bound is enforced (minimum 20 columns / 6 rows). Values up to 65535 are accepted and stored. The geometry change event propagates to Telnet.java:153-158 where it calls: terminal.setSize(new Size(65535, 65535)); terminal.raise(Signal.WINCH); The WINCH signal triggers `LineReaderImpl.handleSignal()` → `redisplay()`. Inside `redisplay()`, multiple paths iterate up to `size.getColumns()` times: - `freshLine()` (LineReaderImpl.java:937,953): loops `size.getColumns()-1` = **65534 iterations**, building and writing a space-padding string across the network socket. - `columnSplitLength(terminal, size.getColumns(), ...)`: called multiple times, each processing all characters against the 65535-wide line width. Because WINCH only fires on *change*, the attacker alternates between two large values (e.g., 65535 and 65534) to trigger an unlimited stream of expensive render cycles. No authentication is required;