The state confusion and response code garbling issue caused by the LIST command

[Wang-jiong-han]

I attempted to test LightFTP using state machine learning technology and found that for the LIST command, if no data connection is established, the server may enter an abnormal state with a certain probability. In this state, the server can receive commands normally but returns garbled response codes. You can refer to the attached state machine diagram below for specific request-response details. I tested this on the old version (5980ea1), the latest release (9a6128d), and the latest commit (d40233b), and the issue persists across all versions.

[hfiref0x]

Hello, no proof-of-concept, code or segfault - nothing to discuss.

[Wang-jiong-han]

Sorry for being too abstract earlier. Specifically, I’ve identified a functional bug: after logging into the server as an anonymous user, if I send the LIST command without establishing a data connection, the server will return 415 for any subsequent command. This might be correct, as the server hasn’t finished processing the data transmission of the previous command. However, after that, the status codes returned by the server for further commands become completely incomprehensible. For example, sending HELP returns 550—a response that should never occur under normal circumstances. Observing the state machine, it seems that after the server sends the 415 response code, the next command will return the original response code of the prior command. For instance: PWD -> 415, HELP -> 550, SYST -> 214. I suspect this may be caused by the message buffer not being cleared in a timely manner. Since I’m not familiar with the LightFTP codebase, I hope you can assist with investigating the exact root cause.

[hfiref0x]

Preliminary it seems the issue is indeed exist and caused by race condition between the main command processing thread and the worker thread. If this bug will be further confirmed it will be fixed in the next version.