REDHAT-BUG-2462351: Double Free

Published Apr 26, 2026
·
Updated

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

Affected Software

1 affected component
redhat/openssh=9.9p1-22.el10_2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Until a fix is shipped, avoid using the affected non-fatal client flow against untrusted hosts. In particular, prefer a client flow that exits before later teardown; avoid the non-fatal DH-GEX client path such as the `ssh-keyscan` flow, and avoid negotiating `diffie-hellman-group-exchange-sha256` in affected FIPS deployments.

    OpenSSH (DH-GEX client) / ssh-keyscan vs ssh Negotiated key exchange = Use/avoid diffie-hellman-group-exchange-sha256 depending on FIPS-mode DH-GEX client path
  2. Operational

    If you must operate with an affected OpenSSH (openssh-9.9p1-22.el10_2 built with OpenSSL support) client in FIPS mode and DH-GEX, run it only against trusted hosts, since the demonstrated double-free requires FIPS mode with `diffie-hellman-group-exchange-sha256` negotiation and a non-fatal client path.

Event History

Apr 26, 2026
Data Sourced
via Red Hat·06:55 PM
DescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of REDHAT-BUG-2462351?

The severity of REDHAT-BUG-2462351 is medium, rated at 4.

2

How do I fix REDHAT-BUG-2462351?

To fix REDHAT-BUG-2462351, update the openssh package to the latest patched version provided by your distribution.

3

What type of vulnerability is REDHAT-BUG-2462351?

REDHAT-BUG-2462351 is a double free vulnerability occurring in the DH-GEX client during FIPS mode checks.

4

What can be exploited in REDHAT-BUG-2462351?

A malicious SSH server can exploit REDHAT-BUG-2462351 to trigger a double free in the DH-GEX client, causing process termination.

5

In which configurations is REDHAT-BUG-2462351 a concern?

REDHAT-BUG-2462351 is a concern in configurations where the openssh package is operating in FIPS mode.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203
REDHAT-BUG-2462351 - Double Free - SecAlerts