urgent security release: 10.6p2

[Damien Miller]

On Thu, 5 Nov 2026, Andy Lutomirski via openssh-unix-dev wrote:

> On Thu, Nov 5, 2026, at 1:10 AM, Damien Miller wrote:
> > OpenSSH 10.6p2 has been released with a workaround for a critical
> > vulnerability.
> >
> > https://openssh.com/releasenotes.html#10.6p2
> >
> > If you operate a Linux system that uses musl libc without
> > PAM (Alpine Linux is one example) then stop reading and set
> > PasswordAuthentication=no or disable SSH for these systems IMMEDIATELY.
> >
> > This vulnerability does not exist on non-Linux systems, Linux/glibc
> > systems and Linux systems that use PAM for password authentication.
> >
> > We consider the root cause of this bug to be outside OpenSSH itself, but
> > we're in a good position to deliver a mitigation quickly.
>
> I tried to analyze the control flow associated with this bug,
> and I'm not sure it's entirely valid to call it musl's bug. musl
> anticipates that someone might call crypt("garbage", "*") and applies
> a workaround:

IMO returning a character that has been used for decades to identify
accounts with disabled passwords regardless of input is absolutely a
bug in musl. This behaviour is not AFAIK documented anywhere and
diverges from other crypt() implementations, which have safer failure
return values.

There is a perfectly good return value on failure: NULL. It's
documented in decades' of POSIX standards for crypt(3) and
unambigously signals what happened to the caller. AIUI (per musl
commit b3c4cc121f70f) returning non-NULL was added to avoid crashes
in applications that called crypt() and failed to handle it
returning NULL, which IMO is an absurd thing to do in a C standard
library.

> At the very least, I think the if (... && pw_password[0] & pw_password[1]) should do something like:
> 
>     else
>         must_fail = true;

Yes, the control flow should be improved and we'll harden auth-passwd.c
against crypt() implementations that do the wrong thing.

-d