Ubuntu OpenSSH GSSAPI error handling flaw can cause denial of service and memory disclosure

Vulnerability in the OpenSSH GSSAPI delta included in various Linux distributions. This vulnerability affects the GSSAPI patches added by various Linux distributions and does not affect the OpenSSH upstream project itself. The usage of sshpkt_disconnect() on an error, which does not terminate the process, allows an attacker to send an unexpected GSSAPI message type during the GSSAPI key exchange to the server, which will call the underlying function and continue the execution of the program without setting the related connection variables. As the variables are not initialized to NULL the code later accesses those uninitialized variables, accessing random memory, which could lead to undefined behavior. The recommended workaround is to use ssh_packet_disconnect() instead, which does terminate the process. The impact of the vulnerability depends heavily on the compiler flag hardening configuration.

• Ubuntu openssh: supplied affected facts confirm these package ranges as affected: 1:10.0p1-5ubuntu5 less than 1:10.0p1-5ubuntu5.1, 1:9.6p1-3ubuntu13 less than 1:9.6p1-3ubuntu13.15, and 1:8.9p1-3 less than 1:8.9p1-3ubuntu0.14. Ubuntu lists fixes at 1:10.0p1-5ubuntu5.1 for 25.10, 1:9.6p1-3ubuntu13.15 for 24.04 LTS, and 1:8.9p1-3ubuntu0.14 for 22.04 LTS.
• Ubuntu 20.04 LTS: Ubuntu's current status page lists a fix at 1:8.2p1-4ubuntu0.13+esm1, available through Ubuntu Pro. The normalized affected range does not provide the lower boundary for this branch, so no broader affected range is inferred here.
• Ubuntu 18.04 LTS and older: Ubuntu lists these as not affected because they use packet_disconnect(), which leads to the correct terminating function. The openssh-ssh1 package is listed as ignored and does not receive security support for this issue.
• Debian: Debian maintenance notices record fixes in 1:10.0p1-7+deb13u2 for trixie-security and 1:9.2p1-2+deb12u9 for bookworm-security. These sources establish fixed releases but do not provide a complete affected range for each branch in the material reviewed.
• Red Hat Enterprise Linux and OpenShift Container Platform: Red Hat confirms that the OpenSSH GSSAPI delta in these products is affected and lists fixed artifacts and errata. The status of layered products or artifacts not listed still requires product-specific validation against Red Hat VEX and advisories.

The flaw is in the GSSAPI key exchange implementation carried as a distribution-specific patch by some Linux distributions, not in the OpenSSH upstream project. When the server receives an unexpected GSSAPI message type, the error path calls sshpkt_disconnect(), which queues a disconnect message and returns instead of terminating the process as ssh_packet_disconnect() does. Execution then continues without initializing related connection variables, causing later code to access uninitialized data or pointers derived from random memory. The source analysis describes recv_tok in the GSSAPI key exchange code being passed through IPC to a privileged monitor and then to gss_release_buffer(), so outcomes can include undefined behavior, a crash, information disclosure, or heap corruption. The confirmed reachability condition is a remote pre-authentication SSH connection; for Ubuntu, GSSAPIKeyExchange must be enabled. The exact impact remains highly dependent on the compiler and hardening options used for the build.

The flaw is remotely reachable during the GSSAPI key exchange, before authentication completes. The source analysis states that an attacker does not need an account, credentials, or user interaction, but the server must use the vulnerable distribution-specific GSSAPI key exchange implementation; for Ubuntu, this is a non-default configuration when GSSAPIKeyExchange is enabled. A specially crafted GSSAPI message can make the daemon continue after the error path and access uninitialized data. Described outcomes include a crash and denial of service, with possible information disclosure or more severe behavior depending on compiler hardening. The supplied record does not identify a public exploit or a known exploited status.

The flaw lets an unauthenticated network connection drive the server into a GSSAPI error path that continues execution with uninitialized variables. The result can be undefined behavior, invalid pointer use, heap corruption, a crash, or denial of service. The technical analysis also describes memory data being sent to a privileged monitor through IPC, creating a potential information disclosure risk. Ubuntu advisory language mentions possible arbitrary code execution depending on compiler hardening, but the available evidence does not establish a reliable code-execution exploit for every build. Real-world organizational impact is most clearly associated with SSH service interruption and possible memory disclosure, while the exact severity depends on the distribution patch, compiler, and hardening configuration.

• A pre-authentication SSH request may crash sshd or interrupt remote administrative access.
• Servers using GSSAPI key exchange should be prioritized for inventory and patching because the attack surface is network reachable without an account.
• Use of uninitialized data may expose part of process memory or affect a privileged monitor process, but the available evidence does not establish a specific data breach.
• Ubuntu advisory language also warns of possible arbitrary code execution depending on compiler hardening; this is a stated possibility, not a confirmed reliable outcome across builds.
• The supplied record does not identify a campaign, victim, breach, or observed exploitation.

1. Update Ubuntu 25.10 to 1:10.0p1-5ubuntu5.1, Ubuntu 24.04 LTS to 1:9.6p1-3ubuntu13.15, and Ubuntu 22.04 LTS to 1:8.9p1-3ubuntu0.14.
2. For Ubuntu 20.04 LTS, apply 1:8.2p1-4ubuntu0.13+esm1; Ubuntu lists this fix as available through Ubuntu Pro.
3. For Debian, update trixie-security to 1:10.0p1-7+deb13u2 or bookworm-security to 1:9.2p1-2+deb12u9, according to the deployed branch.
4. For Red Hat Enterprise Linux and OpenShift Container Platform, apply the Red Hat erratum or fixed artifact for the specific product and release channel. Do not infer safety from the upstream version alone because Red Hat may backport fixes.
5. If an update cannot be deployed immediately, the distribution maintainer should replace sshpkt_disconnect() with ssh_packet_disconnect() at the affected GSSAPI key exchange call sites and rebuild the package. This is the workaround recommended by the technical source, not proof that every deployment has been mitigated.
6. Identify servers with GSSAPIKeyExchange enabled and assess configuration changes using the vendor's guidance. The available evidence confirms this condition for the Ubuntu scope, but does not provide a universal disablement procedure for all distributions.

• Inventory SSH servers and identify the distribution or product providing the openssh package, because the flaw is in distribution GSSAPI deltas rather than OpenSSH upstream.
• Inspect daemon configuration to determine whether GSSAPIKeyExchange is enabled. This is directly relevant to the Ubuntu scope described by the advisory.
• Compare installed package versions with the branch-specific fixed releases in affected_summary, rather than relying only on the upstream OpenSSH version.
• For Red Hat or OpenShift images, compare the product and artifact status with Red Hat errata and VEX data instead of inferring exposure from upstream package versions, because fixes may be backported.
• As a precaution, review telemetry for sshd crashes, restarts, SIGSEGV, or SIGABRT near pre-authentication GSSAPI sessions. This is precautionary monitoring, not a confirmed IOC; absence of such logs does not prove safety.