What I suggest you do here is consider connecting stderr (and stdout) in your fork code (child) to a TCP Stream Socket, then the kftpd thread can monitor the socket for 'data' (via a normal read of a file descriptor) and feed any data back that arrives on the socket back to the ftp client.
You could use a pipe - it would be easy to do in the fork() code and is what the 'tee' command does now, it would only need to be a one way pipe (i.e. from child to kftpd thread). Stdin is assumed to come from elsewhere or is not available (not opened) before execing the userland app.

the kftpd threa can know when the child died by the socket/pipe being closed (giving EOF to the readingend of the descriptor) and/or by the process generating a SIGCHLD.
[thus exiting the 'wait for child process to exit' loop].

Of course if the child launches a app that never exits and thus never closes stderr then you get a stuck kftpd client session.

But thats probably less likely than anything else going wrong and would be a good indication of a badly behavedTM application.