Dear Alexander, Thanks for notifying! Yes, GSSAPIKeyExchange should be mentioned instead of GSSAPIAuthentication.
On Sat, Mar 14, 2026 at 8:50 PM Solar Designer <[email protected]> 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
