Re: OpenSSH GSSAPI keyex patch issue

[Dmitry Belyavskiy <dbelyavs () redhat com>]

Dear Alexander,

Thanks for notifying!
Yes, GSSAPIKeyExchange should be mentioned instead of GSSAPIAuthentication.

On Sat, Mar 14, 2026 at 8:50 PM Solar Designer <solar () openwall com> wrote:

> On Thu, Mar 12, 2026 at 02:03:23PM -0400, Marc Deslauriers wrote:
> > Jeremy Brown discovered a security issue in the GSSAPI Key Exchange
> patch a
> > lot of distros carry on top of the OpenSSH package.
>
> I'm Bcc'ing Jeremy on this.  Thank you for discovering and reporting
> the issue, Jeremy!
>
> > Unfortunately, there seems to be quite a few different versions of this
> > patch being used, but a lot of them share the same core issue. Different
> > compiler options also result in different outcomes, so the severity of
> this
> > issue varies.
> >
> > We have assigned CVE-2026-3497 to this issue.
> >
> > Attached is the full pdf from the reporter, along with the patch we used
> in
> > Ubuntu. I suggest reading the full pdf, but I have extracted some of the
> > most important excerpts from it:
> >
> > "The patch contains a code defect where sshpkt_disconnect() (a
> > non-terminating function that queues a disconnect message and returns)
> is
> > used where ssh_packet_disconnect()(which terminates the process) was
> > intended. This causes the default: error-handling case in the GSSAPI KEX
> > server loop to fall through into code that reads an uninitialized stack
> > variable (recv_tok), sends its contents to the privileged monitor
> process
> > via IPC, and then passes it to gss_release_buffer() which may call
> free()
> > on a garbage pointer."
> >
> > "Bug: Non-terminating error handler (sshpkt_disconnect) in GSSAPI KEX
> server
> > code allows fallthrough to uninitialized variable use
> >
> > - Impact: Pre-auth uninitialized pointer dereference (CWE-824, CWE-908);
> > confirmed heap corruption via free() on uninitialized pointer (SIGABRT
> on
> > x86_64); privsep boundary violation (up to 127KB of heap data to root
> > monitor via IPC); SIGSEGV (signal 11) and SIGABRT (signal 6) on x86_64
> with
> > 90-second SSH lockout; 100% reliable child process crash
> >
> > - Trigger: Single crafted SSH packet (~300 bytes), no authentication or
> > credentials needed
> >
> > - Potentially Affected: Ubuntu/Debian OpenSSH servers with
> GSSAPIKeyExchange
> > yes
>
> Red Hat has now acknowledged that RHEL 8, 9, 10 are also affected (but 6
> and 7 are not):
>
> https://access.redhat.com/security/cve/cve-2026-3497
>
> They suggest setting "GSSAPIAuthentication no" to mitigate this, which I
> find puzzling.  Per the brief discussion we had on the distros list
> pre-disclosure, it appeared that GSSAPIKeyExchange is the option, and
> moreover it was said that GSSAPIKeyExchange could conceivably be used
> without GSSAPIAuthentication.  So which of these two options is/are
> actually responsible for exposing the vulnerability?  Does it maybe vary
> by patch revision (Debian vs. Red Hat) or (more likely?) is this just an
> error in the current Red Hat statement?
>
> Also, the statement is worded such that it's implied the default
> configuration is affected and the mitigation needs to be applied, but
> prior understanding was that these features are disabled by default.
>
> > - Potential Fix: Replace sshpkt_disconnect() with
> ssh_packet_disconnect()
> > at the 3 server-side call sites in kexgsss.c"
> >
> > "The uninitialized recv_tok contains different stack residue depending
> on
> > compiler, optimization level, and flags."
> >
> > "Different compilers produce fundamentally different residue. Clang -O0
> > leaves 0xfffbe600 with length 4. GCC -O2 -fno-stack-protector leaves a
> > valid heap address with length 127344. The 8-build matrix shows that
> > recv_tok.value ranges from NULL to stack addresses to heap addresses to
> > unmapped addresses."
>
> Thank you for bringing this to oss-security, Marc!
>
> Alexander

-- 
Dmitry Belyavskiy