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?
--
Colin Watson (he/him) [cjwat...@debian.org]
