FWIW, I can reproduce it:
lshd: write_buffer: do_write length = 256 lshd: write_buffer: do_write closure->length = 293 lshd: garbage collecting... lshd: gc_mark: Memory corrupted! Aborted
I think it has nothing to do with the actual bits sent, but rather that some earlier random data caused the code to take a rarely tested execution path, which has garbage collect bugs in it, which is discovered a while later.
In general, as an alternative, perhaps a fork() solution will be less vulnerable to these problems.
Btw, is there a way to make the GC more aggressive? E.g., run it after every NEW or KILL? I could use this to track down a GC bug in my patched lsh version.
Bennett Todd bet@rahul.net writes:
on Red Hat 8, I can reliably crash lshd, shutting down all active sessions and leaving a pid file around so lshd refuses to restart, by running
dd if=/dev/random bs=1024 count=1|nc localhost >/dev/null
a few times. Sadly, capturing the random sequence that blows down an lshd and replaying it against another one doesn't seem to kill it; different running instances require different replays of the same random to kill them.
Oh well, back to bloody openssh with all its bugs and patches. Drat!
-Bennett