C daemon creates a general protection fault when client disconnects

[cpswan]

Describe the bug

When a client disconnects from the C daemon (running on OpenWRT) a message like this shows in the system log:

[  344.115795] traps: sshnpd[2540] general protection fault ip:7f9a6e754edf sp:7ffecf34cf58 error:0 in libc.so[7f9a6e744000+4c000]

We also get this in the general logs:

Wed Oct 16 16:15:20 2024 authpriv.info dropbear[2541]: Exit (root) from <::1:40072>: Disconnect received
Wed Oct 16 16:15:20 2024 daemon.info sshnpd[1682]: [WARN] 2024-10-16 16:15:20.786001 | child_exit_handler | Received signal: 1853387673
Wed Oct 16 16:15:20 2024 kern.info kernel: [  344.115795] traps: sshnpd[2540] general protection fault ip:7f9a6e754edf sp:7ffecf34cf58 error:0 in libc.so[7f9a6e744000+4c000]

Steps to reproduce

1. First I install the csshnpd package on an OpenWRT test VM
2. Then I configure the daemon and copy a key in place
3. And then I start the daemon
4. Connect with sshnp from my WSL2
5. Disconnect (cleanly) with ^d

Expected behavior

Normal operation of C daemon does not cause kernel traps.

Additional context

The daemon seems to survive this without being restarted by the init process.

[XavierChanth]

Which version of the code is this running?
We currently have signal traps in place to try and exit cleanly in sshnpd when a ^C is sent, but maybe we should just ditch that idea altogether.

[cpswan]

This is with c0.2.0

[cpswan]

@XavierChanth I know you have #1462 open for this, but that hasn't been merged, and I'm not seeing the issue when testing with c0.2.3, so possibly some other changes have made the problem go away.

Here's what I now see in the general logs:

Mon Nov 11 14:25:32 2024 authpriv.info dropbear[3924]: Exit (root) from <::1:59870>: Disconnect received
Mon Nov 11 14:25:32 2024 daemon.info sshnpd[3882]: [WARN] 2024-11-11 14:25:32.632510 | child_exit_handler | Received signal: 0

and there's nothing in the system log (or springing up on the console).

[XavierChanth]

@XavierChanth I know you have #1462 open for this, but that hasn't been merged, and I'm not seeing the issue when testing with c0.2.3, so possibly some other changes have made the problem go away.

Here's what I now see in the general logs:

Mon Nov 11 14:25:32 2024 authpriv.info dropbear[3924]: Exit (root) from <::1:59870>: Disconnect received
Mon Nov 11 14:25:32 2024 daemon.info sshnpd[3882]: [WARN] 2024-11-11 14:25:32.632510 | child_exit_handler | Received signal: 0

and there's nothing in the system log (or springing up on the console).

@cconstab pointed out it was a problem affecting systemd restarts for him, since it required a double trap to properly kill the process.

The second trap essentially does what not trapping at all would, hence I removed the trap.

[XavierChanth]

I'll do a git diff to see if anything obvious sticks out