urgent security release: 10.6p2

[Loganaden Velvindron]

On Fri, 06 Nov 2026, 05:52 Damien Miller, <djm at mindrot.org> wrote:

>
>
> 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.
>

Adding workarounds in any libc for such an issue isn't the right way imho.
Upstream software not calling crypt() properly should fix this imho.

>
> > 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
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>