Bug#1103418: openssh-server irregularly crashing since 10.0p1 upgrade

On Thu, Apr 17, 2025 at 11:08:08PM -0600, Liam Stitt wrote:
>This minor speedbump aside, I have attached the 'bt' output from gdb.

Ugh, I didn't realize your password would show up in the backtrace!  
Sorry about that - please change it as soon as possible.

That said, the backtrace is definitely useful, but inconclusive.  It 
shows that the crash is nominally inside pam_ecryptfs, but the asprintf 
call that's crashing looks fine to me, and the backtrace shows that its 
arguments are valid.  Therefore I think we must be dealing with action 
at a distance from some previous memory corruption, which is going to be 
a pain to track down.  It might be in openssh-server, and the timing 
suggests that it probably is; but it might also be in any other PAM 
module used in the auth phase.

My next best plan is to try valgrind, which is usually good at spotting 
these kinds of memory corruption errors.  Setting this up is a little 
involved in this case, but not too bad.  Here are instructions I've 
tested in a container:

  * install the valgrind package
  * as root, create /usr/local/bin/sshd-session-valgrind with the 
    following contents:

#! /bin/sh
exec valgrind /usr/lib/openssh/sshd-session "$@"

  * sudo chmod +x /usr/local/bin/sshd-session-valgrind
  * as root, create /etc/ssh/sshd_config.d/valgrind.conf with the 
    following contents:

SshdSessionPath /usr/local/bin/sshd-session-valgrind

  * sudo systemctl restart ssh.service

Now try logging in again until you hit a crash, and then look in "sudo 
journalctl -u ssh.service | less" for the output of valgrind; each 
instance of its output will start with a line saying "Memcheck, a memory 
error detector", and each line will have "==PID==" in it for some 
process ID.  I don't think the output is likely to include your password 
this time, but it will probably be worth checking it over just in case.

Separately, it might also be helpful for me to have a copy of your 
/etc/pam.d/common-auth file, so I can see which other modules are being 
run in this phase.  My guess is that this probably won't help me, but 
it's easy to capture and it stands some chance of letting me reproduce 
this locally, which would be a big help.

Thanks,