ValentinBouffard opened a new issue, #891: URL: https://github.com/apache/mina-sshd/issues/891
### Version 3.0.0-M2 ### Bug description ## Summary Intermittent SFTP upload failures when using Apache MINA SSHD **3.0.0-M2** as a client. The remote server (ProFTPD `mod_sftp`) receives a malformed `SSH_MSG_IGNORE` packet and terminates the session. The issue was not observed on 2.x. ## Environment | Component | Version | |-----------------|------------------------| | MINA SSHD | 3.0.0-M2 | | Java | 25 | | Remote server | ProFTPD mod_sftp/1.0.0 | | Protocol | SFTP (file upload) | ## Server-side error ``` mod_sftp/1.0.0: message format error: unable to read 2594667651 bytes of string data (buflen = 20) ``` ``` -----BEGIN STACK TRACE----- [0] /usr/libexec/proftpd/mod_sftp.so(sftp_msg_read_string+0x5d) [1] /usr/libexec/proftpd/mod_sftp.so(sftp_ssh2_packet_handle_ignore+0x20) [2] /usr/libexec/proftpd/mod_sftp.so(sftp_ssh2_packet_handle+0x168) -----END STACK TRACE----- ``` The value **2594667651** (`0x9AA1FA83`) appears to be corrupted data being interpreted as a string length field. ## Reproduction conditions - Occurs during **active file transfers** (~6.5 MB uploads), not during idle periods. - The packet was decrypted and MAC-verified by the server โ this rules out in-transit corruption. The payload itself is malformed. - `IGNORE_MESSAGE_FREQUENCY` is at its default value (`1024`). - `HEARTBEAT_INTERVAL` is set to `15s` (uses `SSH_MSG_GLOBAL_REQUEST` by default in 3.0.0-M2). - **Not reproducible on 2.x.** ## Workaround Setting `IGNORE_MESSAGE_FREQUENCY = 0` prevents the issue entirely, which confirms the problem is tied to the periodic `SSH_MSG_IGNORE` injection rather than the heartbeat mechanism. ## Root cause suspicion `AbstractSession` was significantly refactored in **3.0.0-M1** (moved to a filter chain architecture). In 2.17.1, `doWritePacket()` used an `encodeLock` around packet encoding and writing, ensuring atomicity. We suspect the new filter chain architecture may have a **synchronization gap** when injecting `SSH_MSG_IGNORE` packets concurrently with data packets โ i.e., a race condition where the ignore packet's encoding overlaps with a data packet write, resulting in a corrupted payload on the wire. The `0x9AA1FA83` value is consistent with partially overwritten buffer contents rather than a clean encoding error. ### Actual behavior The remote server receives an `SSH_MSG_IGNORE` packet whose string length field contains corrupted data (`2594667651` / `0x9AA1FA83`) instead of the expected small value (~16 bytes). The packet passes MAC verification, so the corruption originates in payload construction, not in transit. The server terminates the session with: ``` message format error: unable to read 2594667651 bytes of string data (buflen = 20) ``` Not reproducible on 2.x. ### Expected behavior SSH_MSG_IGNORE packets injected by the traffic analysis countermeasure must contain a well-formed SSH string (uint32 length + data) per RFC 4253 ยง11.2. Instead, the string length field contains what appears to be corrupted buffer data (0x9AA1FA83), causing the remote server to reject the packet. Relevant logs: None on client side โ the error is reported by the remote server (ProFTPD mod_sftp). Additional context: AbstractSession was significantly refactored in 3.0.0-M1, moving to a filter chain architecture. In 2.17.1, doWritePacket() held an encodeLock around both the encoding and writing of the injected SSH_MSG_IGNORE and the data packet, ensuring atomicity. We suspect the new architecture may have introduced a synchronization gap in that path. Java version: 25. ### Relevant log output ```Shell -----BEGIN STACK TRACE----- [0] /usr/libexec/proftpd/mod_sftp.so(sftp_msg_read_string+0x5d) [1] /usr/libexec/proftpd/mod_sftp.so(sftp_ssh2_packet_handle_ignore+0x20) [2] /usr/libexec/proftpd/mod_sftp.so(sftp_ssh2_packet_handle+0x168) -----END STACK TRACE---- ``` ### Other information _No response_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
