OpenSSH server fails to terminate executed program under certain conditions

[Lucas Mulling]

Hello,

We started experiencing failures in all architectures in a libssh test after
updating to OpenSSH 10.0p2. The test in question is
torture_channel_exit_signal, relevant code below:

    rc = snprintf(request, sizeof(request), "cat");
    [...]
    /* Make the request, read parts with close */
    rc = ssh_channel_request_exec(channel, request);
    assert_ssh_return_code(session, rc);
    rc = ssh_channel_request_send_signal(channel, "TERM");
    assert_ssh_return_code(session, rc);

    exit_status = ssh_channel_get_exit_state(channel,
                                             &exit_status,
                                             &exit_signal,
                                             &core_dumped);

In debugging I've found that the test requests SIGTERM so fast that the server
-- OpenSSH -- has not had yet time to properly setup the child, resulting in
killpg from session_signal_req failing (see log bellow).

OpenSSH was build with:
./configure                            \
    --with-pam                         \
    --with-privsep-path=/var/lib/empty \
    --with-systemd --libexecdir=$(pwd)

With an added log to:
@@ -1508,6 +1513,8 @@ do_child(struct ssh *ssh, Session *s, const char *command)
        struct passwd *pw = s->pw;
        int r = 0;

+       debug2("do child");
+
        sshpkt_fmt_connection_id(ssh, remote_id, sizeof(remote_id));

        /* remove keys from memory */

Relevant log snippet:
debug3: send packet: type 99
debug3: receive packet: type 98
debug1: server_input_channel_req: channel 0 request signal reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req signal
debug1: session_signal_req: signal TERM, killpg(458610, 15)
debug1: temporarily_use_uid: 5001/9000 (e=5001/9000)
debug1: restore_uid: (unprivileged)
session_signal_req: status(0)
session_signal_req: killpg(458610, 15): No such process
debug2: do child

Note that do_child is called after killpg is called, this means (in my
understating) that the correct gid has not been setup for killpg to
work. This would, probably, not happen in a real world use case due to
network delays.

Could you clarify if this behaviour is intended?