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

Colin Watson <[email protected]>
Newsgroups gmane.linux.debian.devel.ssh
Message-ID <aAUCS1XTn07uL4C3__28340.9730576508$1745158888$gmane$org@riva.ucam.org>
On Sat, Apr 19, 2025 at 03:25:17AM -0600, Liam Stitt wrote:
>On Fri, 18 Apr 2025, Colin Watson wrote:
>>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.
>
>Before I continue, I just remembered another issue (possibly 
>PAM-related) which had come up irregularly enough to forget about, but 
>may be smoke here.
>
>Every so often, logging in normally behaves but also spits out:
>
>"When trying to update a password, this return status indicates that 
>the value provided as the current password is not correct."
>
>which is some sort of Samba error. Maybe there's an interaction here.

Could be.  I've installed libpam-winbind in my test container but still 
can't reproduce this.  (I don't have a full Samba setup to test against, 
though.)

>Now as to your new instructions:
>
>>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.
>
>Typical such output attached.

This output seems to show an authentication failure of some kind 
(ignoring pam_unix, pam_winbind succeeds, but then the account stage 
fails), which doesn't seem to be quite the same as the segfault you 
reported previously.  It might be that these two things are related in 
some way, but I was really hoping that you would be able to catch 
specifically the segfault under valgrind.  Is that at all possible, or 
does inserting valgrind somehow reliably make the segfault go away?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.