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) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Apr 25, 2025 at 02:01:29PM +0200, Andreas Kurth wrote:

Hello Liam, Colin,

You didn't CC Liam so he may not have seen your message. I've added the
CC here.

given that nobody confirmed this issue for more than a week and it seems
to be a rather particular case: does this really need to have "grave" >severity? It deters users from updating their systems.

For now the release team has ignored it to allow migration to testing.
I'm going to leave it at its current severity for the time being though;
if anyone else is encountering the same thing then it would be useful
for me to know, to try to narrow down some way to reproduce it, and a
bit of extra attention from the higher severity won't hurt.

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Package: openssh-server
Version: 1:10.0p1-2
Followup-For: Bug #1103418
X-Debbugs-Cc: lucio@sulweb.org

I'm afraid my previous message is misleading. Upon trying again, in
order to get the logs, I noticed the behavior is not always reproducible, so the discriminating
factor can't be the presence of the username. Sorry for the background noise.

-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'stable'), (700, 'unstable'), (500, 'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.14.0 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii debconf [debconf-2.0] 1.5.91
ii init-system-helpers 1.68
ii libaudit1 1:4.0.2-2+b2
ii libc6 2.41-7
ii libcom-err2 1.47.2-1+b1
ii libcrypt1 1:4.4.38-1
ii libgssapi-krb5-2 1.21.3-5
ii libkrb5-3 1.21.3-5
ii libpam-modules 1.7.0-3
ii libpam-runtime 1.7.0-3
ii libpam0g 1.7.0-3
ii libselinux1 3.8.1-1
ii libssl3t64 3.5.0-1
ii libwrap0 7.6.q-36
ii libwtmpdb0 0.73.0-2
ii lsb-base 11.6
ii openssh-client 1:10.0p1-2
ii openssh-sftp-server 1:10.0p1-2
ii procps 2:4.0.4-8
ii runit-helper 2.16.4
ii systemd [systemd-sysusers] 257.5-2
ii sysvinit-utils [lsb-base] 3.14-4
ii ucf 3.0051
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages openssh-server recommends:
ii libpam-systemd [logind] 257.5-2
ii ncurses-term 6.5+20250216-2
ii xauth 1:1.1.2-1.1

Versions of packages openssh-server suggests:
pn molly-guard <none>
pn monkeysphere <none>
pn ssh-askpass <none>
pn ufw <none>

-- debconf information excluded

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3822

On Tue, May 06, 2025 at 07:28:59PM +0200, Michel Casabona wrote:

Sorry for the delay. Here are the results from some testing.
It seems that the problem may be related to pam_ecryptfs, after all

[...]

* To exclude any local things and remnants from years of experiments
on my desktop machine, I've setup new virtual machines
(using libvirt / virt-manager, AMD64, UEFI if that matters) as follows:

- install trixie with the Debian installer Trixie Alpha 1 (netinst)
- no desktop, only ssh server
- add a few convenience packages (sudo mc vim)
- add debugging packages (systemd-coredump, gdb, debuginfod, valgrind)
at this point ssh seems to work correctly

- add ecryptfs-utils (+ cryptsetup / rsync)
then ssh-session starts to crash most of the time

Thanks, this was extremely helpful! I was finally able to reproduce
this bug, and tracked it down to the --with-linux-memlock-onfault
configure option. I forwarded this to https://bugzilla.mindrot.org/show_bug.cgi?id=3822.

I'm going to disable this option again for now, as it's a recent
addition and isn't security-critical.

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)