A flaw was found in OpenSSH. This vulnerability, a heap out-of-bounds read, occurs during the cleanup of GSSAPI (Generic Security Service Application Programming Interface) indicators when a trailing NULL termination is missing in the auth-indicators array. A remote attacker, under specific configurations involving GSSAPI authentication and a Kerberos environment, could exploit this to cause the SSH authentication path to crash or abort. This leads to a denial of service (DoS), impacting the availability of the SSH service.

AIONLYREPORT package: openssh-9.9p1-22.el102 ------ Summary: Double Free in DH-GEX Client during FIPS Mode Check: a malicious SSH server can trigger a double free in the DH-GEX client path during FIPS known-group validation, leading to client-side process termination in affected configurations. Requirements to exploit: An affected openssh-9.9p1-22.el102 client build with OpenSSL support must run in FIPS mode, negotiate diffie-hellman-group-exchange-sha256, and process attacker-controlled DH-GEX group parameters; the clearest demonstrated second-free path is a non-fatal client flow such as ssh-keyscan. Component affected: openssh-9.9p1-22.el102: DH-GEX client handling in kexgexc.c (inputkexdhgexgroup()), with later teardown in kex.c (kexfree()). Version affected: openssh-9.9p1-22.el102 when built with OpenSSL support and used in FIPS mode with diffie-hellman-group-exchange-sha256 negotiated Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - 5.9 (MEDIUM) AV:N - The triggering input is delivered by a remote SSH server during key exchange. AC:L - In an affected configuration, the attacker only needs to return a size-valid DH group that fails the FIPS known-group check. PR:N - No authentication or prior access to the client is required. UI:R - A user or automation must initiate the SSH connection or scan to the attacker-controlled server. S:U - The impact is confined to the vulnerable client process. C:N - No confidentiality impact is established by the available evidence. I:N - No integrity impact is established by the available evidence. A:H - The demonstrated outcome is a reachable double free that can abort or terminate the affected client process. Impact: Moderate. This is a remote, availability-focused flaw, but the demonstrated double-free path depends on FIPS mode, DH-GEX negotiation, and a client flow that continues to teardown after the validation error. Because the available evidence supports process termination rather than broader compromise, and the common ssh client path often exits before the second free, this fits Red Hat's Moderate category rather than Important. Embargo: no Reason: The established impact is client-side denial of service in a constrained FIPS/DH-GEX path, with no demonstrated confidentiality or integrity loss and a straightforward local fix. Acknowledgement: Aisle Research Vulnerability Details: In inputkexdhgexgroup(), the client parses server-supplied p and g, transfers them into kex->dh via dhnewgroup(), and only then performs the FIPS known-group validation. If that validation fails, execution jumps to out before the local pointers are nulled. The local cleanup then frees BIGNUMs that are already owned by kex->dh, and later teardown can free the same objects again through DHfree(kex->dh). c if ((kex->dh = dhnewgroup(g, p)) == NULL) { r = SSHERRALLOCFAIL; goto out; } if (FIPSmode() && dhisknowngroup(kex->dh) == 0) { r = SSHERRINVALIDARGUMENT; goto out; } p = g = NULL; / belong to kex->dh now / ... out: BNclearfree(p); BNclearfree(g); return r; The ownership transfer happens in dhnewgroup() through DHset0pqg(): c if ((dh = DHnew()) == NULL) return NULL; if (!DHset0pqg(dh, modulus, NULL, gen)) { DHfree(dh); return NULL; } return dh; The practical reachability is nuanced. In the normal ssh client flow, fatal dispatch commonly exits immediately before later teardown, which reduces impact there. In contrast, the ssh-keyscan client flow uses non-fatal dispatch and later closes the SSH state, reaching kexfree() and a second DHfree(kex->dh). Based on the available evidence, this supports a real double free with demonstrated availability impact, but not a demonstrated confidentiality or integrity impact. Steps to reproduce: 1. Use an affected openssh-9.9p1-22.el102 build with OpenSSL support and run it in FIPS mode. 2. Exercise a non-fatal DH-GEX client path, such as the ssh-keyscan flow present in this source tree. 3. Ensure diffie-hellman-group-exchange-sha256 is negotiated with an attacker-controlled SSH server. 4. Have the server return (p, g) values that pass the size check in inputkexdhgexgroup() but fail dhisknowngroup(). 5. Observe the first free at BNclearfree(p) / BNclearfree(g) on the goto out path, followed by a second free during later teardown when sshpacketclose() reaches kexfree() and calls DHfree(kex->dh). Mitigation: Until a fix is shipped, avoid negotiating diffie-hellman-group-exchange-sha256 in affected FIPS deployments and avoid using the affected non-fatal client flow against untrusted hosts while FIPS mode is enabled. Proposed Fix: Move the pointer nulling immediately after successful dhnewgroup() so all later error paths treat ownership correctly. diff diff --git a/kexgexc.c b/kexgexc.c @@ -115,12 +115,12 @@ inputkexdhgexgroup(int type, uint32t seq, struct ssh ssh) if ((kex->dh = dhnewgroup(g, p)) == NULL) { r = SSHERRALLOCFAIL; goto out; } + p = g = NULL; / belong to kex->dh now / if (FIPSmode() && dhisknowngroup(kex->dh) == 0) { r = SSHERRINVALIDARGUMENT; goto out; } p = g = NULL; / belong to kex->dh now /

------ This report was generated using AI technology. Always review AI-generated content prior to use

Dear Alexander,

On Wed, Mar 18, 2026 at 3:09 PM Solar Designer <solar () openwall com> wrote: Hi Dmitry,

On Wed, Mar 18, 2026 at 09:14:31AM +0100, Dmitry Belyavskiy wrote: Can we somehow establish some better coordination in case of widely used downstream patches, especially for such an important, ubiquitous and heavily patched component as OpenSSH? This was brought to the distros list on March 5. On March 6, I wrote:

"Looks like Red Hat packages are also affected. In particular, I looked at openssh-8.0p1-gssapi-keyex.patch from RHEL 9."

so it's not like Red Hat could assume this was limited to Debian/Ubuntu.

I now recall that something similar happened on a previous occasion, where you were not aware of a relevant issue until public disclosure.

So we seem to have a question to the Red Hat security team here - are you going to be informing your package maintainers of embargoed issues (which I consider fitting the need-to-know condition of the distros list), or are you deliberately handling them differently, or neither? Thanks, I will investigate it. I suppose this could reasonably vary by package - security updates to be prepared by security team vs. by package maintainer.

Should I be taking care of notifying Dmitry for OpenSSH specifically, where we know that he's eager to prepare for these disclosures but is often left out of the loop? IIRC, from the previous occasion I actually planned to start doing that, but I forgot, I'm sorry. No problem, thank you! I think OpenSSH, being heavily patched, deserves some special procedure, and can invite you to the discussion, if you are interested.

Meanwhile, I see the Mitigation section in https://access.redhat.com/security/cve/cve-2026-3497 has been updated to correctly refer to GSSAPI key exchange rather than authentication, but it still seems to imply the default configuration is affected - which I think it is not, or is it? I don't think so; I'll double-check. I wasn't too concerned about this issue for the Rocky Linux SIG/Security package that I maintain because we build it without Kerberos and GSSAPI support since March 2024. The patch is still applied, but the GSSAPIKeyExchange setting does not exist for real (is silently ignored via an extra patch for compatibility with FIPS configs that disable it), so it can't possibly be enabled there. Ditto in CIQ's RLC Pro Hardened. Thank you very much!

-- Dmitry Belyavskiy

Hi Dmitry,

On Wed, Mar 18, 2026 at 09:14:31AM +0100, Dmitry Belyavskiy wrote: Can we somehow establish some better coordination in case of widely used downstream patches, especially for such an important, ubiquitous and heavily patched component as OpenSSH? This was brought to the distros list on March 5. On March 6, I wrote:

"Looks like Red Hat packages are also affected. In particular, I looked at openssh-8.0p1-gssapi-keyex.patch from RHEL 9."

so it's not like Red Hat could assume this was limited to Debian/Ubuntu.

I now recall that something similar happened on a previous occasion, where you were not aware of a relevant issue until public disclosure.

So we seem to have a question to the Red Hat security team here - are you going to be informing your package maintainers of embargoed issues (which I consider fitting the need-to-know condition of the distros list), or are you deliberately handling them differently, or neither?

I suppose this could reasonably vary by package - security updates to be prepared by security team vs. by package maintainer.

Should I be taking care of notifying Dmitry for OpenSSH specifically, where we know that he's eager to prepare for these disclosures but is often left out of the loop? IIRC, from the previous occasion I actually planned to start doing that, but I forgot, I'm sorry.

Meanwhile, I see the Mitigation section in https://access.redhat.com/security/cve/cve-2026-3497 has been updated to correctly refer to GSSAPI key exchange rather than authentication, but it still seems to imply the default configuration is affected - which I think it is not, or is it?

I wasn't too concerned about this issue for the Rocky Linux SIG/Security package that I maintain because we build it without Kerberos and GSSAPI support since March 2024. The patch is still applied, but the GSSAPIKeyExchange setting does not exist for real (is silently ignored via an extra patch for compatibility with FIPS configs that disable it), so it can't possibly be enabled there. Ditto in CIQ's RLC Pro Hardened.

Alexander

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 sshpktdisconnect() (a non-terminating function that queues a disconnect message and returns) is used where sshpacketdisconnect()(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 (recvtok), sends its contents to the privileged monitor process via IPC, and then passes it to gssreleasebuffer() which may call free() on a garbage pointer."

"Bug: Non-terminating error handler (sshpktdisconnect) 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 x8664); privsep boundary violation (up to 127KB of heap data to root monitor via IPC); SIGSEGV (signal 11) and SIGABRT (signal 6) on x8664 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 sshpktdisconnect() with sshpacketdisconnect() at the 3 server-side call sites in kexgsss.c"

"The uninitialized recvtok 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 recvtok.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

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 sshpktdisconnect() (a non-terminating function that queues a disconnect message and returns) is used where sshpacketdisconnect()(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 (recvtok), sends its contents to the privileged monitor process via IPC, and then passes it to gssreleasebuffer() which may call free() on a garbage pointer."

"Bug: Non-terminating error handler (sshpktdisconnect) 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 x8664); privsep boundary violation (up to 127KB of heap data to root monitor via IPC); SIGSEGV (signal 11) and SIGABRT (signal 6) on x8664 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 sshpktdisconnect() with sshpacketdisconnect() at the 3 server-side call sites in kexgsss.c"

"The uninitialized recvtok 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 recvtok.value ranges from NULL to stack addresses to heap addresses to unmapped addresses." Thank you for bringing this to oss-security, Marc!

Alexander