[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOcQRVW0Nestm-mMxnEzbb=cTEy_chVaoy8rm7Aqwc5OkadHVw@mail.gmail.com>
Date: Wed, 18 Mar 2026 09:14:31 +0100
From: Dmitry Belyavskiy <dbelyavs@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: OpenSSH GSSAPI keyex patch issue
Dear colleagues,
Thanks for sharing your findings!
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?
On Thu, Mar 12, 2026 at 7:09 PM Marc Deslauriers <
marc.deslauriers@...onical.com> wrote:
> Hello,
>
> Jeremy Brown discovered a security issue in the GSSAPI Key Exchange patch
> a lot
> of distros carry on top of the OpenSSH package.
>
> 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
>
> - 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."
>
>
> Thanks,
>
> Marc.
> --
> Marc Deslauriers
> Ubuntu Security Engineer | http://www.ubuntu.com/
> Canonical Ltd. | http://www.canonical.com/
>
--
Dmitry Belyavskiy
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
