Bug#1134814: marked as done (openssh-client: Segfault in identity_sign at sshconnect2.c:1418 when using RSA certificates)
"Debian Bug Tracking System" <[email protected]> Mon, 06 Jul 2026 19:21:02 +0000
| Newsgroups | gmane.linux.debian.devel.ssh |
|---|---|
| Message-ID | <handler.1134814.D1134814.17833655691771851.ackdone@bugs.debian.org> |
This is a multi-part message in MIME format... ------------=_1783365662-1772484-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your message dated Mon, 06 Jul 2026 19:19:27 +0000 with message-id <[email protected]> and subject line Bug#1134814: fixed in openssh 1:10.4p1-1 has caused the Debian Bug report #1134814, regarding openssh-client: Segfault in identity_sign at sshconnect2.c:1418 w= hen using RSA certificates to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) --=20 1134814: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1134814 Debian Bug Tracking System Contact [email protected] with problems ------------=_1783365662-1772484-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by bugs.debian.org; 24 Apr 2026 12:09:26 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=4.0 tests=BAYES_00, BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU, DKIM_VALID_EF,FOURLA,FREEMAIL_FROM,HAS_PACKAGE,HTML_MESSAGE,MULTALT, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 46; hammy, 149; neutral, 44; spammy, 1. spammytokens:0.987-1--H*r:60609 hammytokens:0.000-+--forky, 0.000-+--Backtrace, 0.000-+--Segfault, 0.000-+--deb14amd64, 0.000-+--deb14-amd64 Return-path: <[email protected]> Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]:60609) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim 4.96) (envelope-from <[email protected]>) id 1wGFLa-00FVLR-16 for [email protected]; Fri, 24 Apr 2026 12:09:26 +0000 Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-c6dd5b01e14so2764258a12.0 for <[email protected]>; Fri, 24 Apr 2026 05:09:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777032564; cv=none; d=google.com; s=arc-20240605; b=VSnqdPQGGwh1XmIbnL4LiqRjDkWWt1kbqu4k1/iANIl/c9ZlYDB17pbj+ZhJYkWjrI aHoCI88ZhTOHLOinBPODAefgsX3pdTBrPkfmOp14gzCR/1fzdD/zCkF06Ul+atd/uVoj 2eUpseQF+suz73j/lUKyQDoysY6/E9q2282fnSDvpZv5P7bPMAM/gkhPOoD0p0IzqtfB IU5MvYJl8+nDcNyjDT0H4wwtsK0iPSvjSbpL6wzLgw3vZntiOZxnH5KUi42AEmmvPyLh 9VU0ajC++rfP4l4q8rbbdSP5ASPLXmlaWt/EIm3QG/qgqPFBktabuAB/yAt0IvXUgKl3 SHlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=dlz9+mJUQ87EPKuw+WLNLno6rmNKURh8FIFFJpaVwjU=; fh=lIR/7veID2U00tj1D35G+ANF85YwqTAbTuNH/WGncTs=; b=dGBFg992RsMPV4MHLZ+oIiyXvdNyZn5ypFBgv0kZDAWs+6ovW1eXhcgj+JnkaNRVHQ /MedAkX2u1ntRfd/TEKEg2gbRkJoIqyVJ1JI2lACqlXsd4lz9FI3EnaXsVTZzP/WKck0 ttbRr58+U0tdSbW5u5TPoi+YWSGzxDhoKWsU9/SsYGtL8YOX5MNjCxBi3f6y613Evhg2 TI/gtGw05rME7/9pg9gDkanbbFTWYDwhVpgd2KmdNBDeg61ow5h1+2NDE16bjlUoQ9D8 x5mvkanRBDjeVNKElURxnZdvKBeNqGvYnvmjn9KwPZaACQ4ySiZK4h0ub7Xjv+XqG002 Ke/g==; darn=bugs.debian.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777032564; x=1777637364; darn=bugs.debian.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dlz9+mJUQ87EPKuw+WLNLno6rmNKURh8FIFFJpaVwjU=; b=qf/kdzkd9kMBVWmQjEuSkLFujXoQJO68ec673qglbENAVcA9fYLmP3g8747u5qNGH4 IgUG0hGQGx+OJX2sqoecWFjmoRGV/o3kuIPnHINB8XO5vD1mWb8kDLngOhMeJHl8FFVy WKUXLIBdKgfn/d2SO/IOhMlPIl2yLHlq5QdA4/zeYGjlvek5k3DX1/mb+PtXojTdXMwn VV8cSIU64+VQbJinLQM2pR9AF08JTf0nq1wnbOT3bnpLJg5dAeawns4Q+8v7ai2V7N94 dZeWGcOh5FVjd+oPciFgAe68Pu0JlywVkXk0iGcROpAhJqpTHHQvNxoYwCwuwgLLNqiD UNMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777032564; x=1777637364; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dlz9+mJUQ87EPKuw+WLNLno6rmNKURh8FIFFJpaVwjU=; b=QFS2eL5bYBGila5EuQvl5vPXqRx0QNCXIROGIBN7MeeaJ4E3cPXp0H4524/OLU+/Kq o+x0Meyo3UG0ZXX4l2eJAeSheift21W+dEQx113e2/JIXAzix9RtSbCODhlTTq/CMany xpL0l2WLhxkMkBZumKytLLM7j6GM84/ULkf9ueNo9/qTeXcRydmv0cYg8VinJ7jmZyPw +tTxFJBse96LzJDoTNDYqlgnKTFJ5lXKG7RGEN6Zvj+4mJU3lFTXCWS+lXAljBuxdzSF JzhG2tfiCDJfb+ROQNREFzF8fGtkzRmUQ10qprZOnsRfYLizucBpKmNnHkEkn5a4w2Y3 Gp+A== X-Gm-Message-State: AOJu0Ywg3CYcKYQLrwEJnH33QH9qCLPlVfTE6dO59dzYKt4CiDA9iht9 l5Hqm3tWb9Y0L0sOsCxeT4QVSm5vgvQWCqU1N4YcmxPVgxTEdHb2t4JG4ZKKlgxl/b1zEfgNZu1 gtpwdqSgHAyJH2KtQ0jGBya8z1xwYNRIDIfyESfM= X-Gm-Gg: AeBDiessQZ9UVLEcQwRcwkTxPujCLu9EzPE7X48ebCObl1CmFSAeg4OsAlS1zhrjX3g CZKgPLSPTre9eR2LLmmVox8VkLGwP9DaLPUQcKXd5kn3Us6T7IRZtbwsRMiow+MpC9adgah+WIf HGoCcSnLTGvS8Q1Y1fG0gu2G8KWlXcV4VM0mdEumVMuT+GT/9SNZIy+jxCbSTbgkOk4VEGGaq2/ /CP7QBisZFXk33MwTEJfJ06n5pBvsnjEl6hzptYjoaQPZL6oEkzwgvZYCo+rB0pSvlk/fnKUhYm zo3AMWqgoVHT6iWXICEE1/jz9EABfbt7WlKVTyACDsWmhoDIzA84qyNvOu8RNlmm4GVfQgpes7w 477rGZ5+Iv25xYA8F+x3lyY3jOyog4OQ9563ExMw6vUf4mWaf X-Received: by 2002:a17:902:cec6:b0:2b0:917c:bc4 with SMTP id d9443c01a7336-2b5f9e8e3c0mr355216175ad.4.1777032564019; Fri, 24 Apr 2026 05:09:24 -0700 (PDT) MIME-Version: 1.0 From: Alejandro E BM <[email protected]> Date: Fri, 24 Apr 2026 14:09:12 +0200 X-Gm-Features: AQROBzBqKBuu810feGq5GSG9mLXiKTkRwcabrlaiwqM9wTxdxguvDwrkRl-0czE Message-ID: <CABv869Eqd5rO28qgG9vNsXENdvO=qEE6Yn4iAwck=i9+FU+sUQ@mail.gmail.com> Subject: openssh-client: Segfault in identity_sign at sshconnect2.c:1418 when using RSA certificates To: [email protected] Content-Type: multipart/alternative; boundary="000000000000bb9635065033a2ba" Delivered-To: [email protected] --000000000000bb9635065033a2ba Content-Type: text/plain; charset="UTF-8" Package: openssh-client Version: 1:10.3p1-1 Severity: important Tags: patch Dear Maintainer, I encountered a consistent segmentation fault in the ssh client when attempting to authenticate using RSA certificates against a server that supports the [email protected] extension. The crash occurs in sshconnect2.c within the identity_sign() function. Specifically, at line 1418, the code attempts to check id->key->flags without verifying that id->key is not NULL. In my testing with GDB, id->key was indeed NULL at this stage, leading to a null pointer dereference. GDB Backtrace summary: #0 identity_sign (id=0x55..., sigp=0x..., lenp=0x..., data=0x..., datalen=2080, compat=67108864, alg=0x55... "[email protected]") at ../../sshconnect2.c:1418 (gdb) print *id $1 = { ..., key = 0x0, filename = "/root/.ssh/pkey", tried = 1, ... } Here is a patch that adds a NULL check for id->key before dereferencing it, which resolved the issue in my environment. Patch --- sshconnect2.c.orig 2026-04-24 12:04:24.468317131 +0000 +++ sshconnect2.c 2026-04-24 11:22:28.606107940 +0000 @@ -1415,7 +1415,7 @@ * PKCS#11 tokens may not support all signature algorithms, * so check what we get back. */ - if ((id->key->flags & SSHKEY_FLAG_EXT) != 0 && + if (id->key != NULL && (id->key->flags & SSHKEY_FLAG_EXT) != 0 && (r = sshkey_check_sigtype(*sigp, *lenp, alg)) != 0) { debug_fr(r, "sshkey_check_sigtype"); goto out; -- System Information: Debian Release: 14 (forky) Architecture: amd64 Kernel: 6.19.11+deb14-amd64 Cheer Alejandro --000000000000bb9635065033a2ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><p>Package: openssh-client<br>Version: 1:10.3p1-1<br>Sever= ity: important<br>Tags: patch<br><br>Dear Maintainer,<br><br>I encountered = a consistent segmentation fault in the ssh client when attempting<br>to aut= henticate using RSA certificates against a server that supports <br>the <a = href=3D"mailto:[email protected]">publickey-hostbound-v00= @openssh.com</a> extension.<br><br>The crash occurs in sshconnect2.c within= the identity_sign() function. <br>Specifically, at line 1418, the code att= empts to check id->key->flags <br>without verifying that id->key i= s not NULL. In my testing with GDB, <br>id->key was indeed NULL at this = stage, leading to a null pointer dereference.<br><br>GDB Backtrace summary:= <br>#0 =C2=A0identity_sign (id=3D0x55..., sigp=3D0x..., lenp=3D0x..., data= =3D0x..., datalen=3D2080, <br>=C2=A0 =C2=A0 compat=3D67108864, alg=3D0x55..= . "<a href=3D"mailto:[email protected]">rsa-sha2-256-c= [email protected]</a>") <br>=C2=A0 =C2=A0 at ../../sshconnect2.c:141= 8<br><br>(gdb) print *id<br>$1 =3D { ..., key =3D 0x0, filename =3D "/= root/.ssh/pkey", tried =3D 1, ... }<br><br>Here is a patch that adds a= NULL check for id->key before <br>dereferencing it, which resolved the = issue in my environment.<br><br>Patch</p><p>--- sshconnect2.c.orig =C2=A020= 26-04-24 12:04:24.468317131 +0000<br>+++ sshconnect2.c =C2=A0 =C2=A0 =C2=A0= 2026-04-24 11:22:28.606107940 +0000<br>@@ -1415,7 +1415,7 @@<br>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0* PKCS#11 tokens may not support all signature algo= rithms,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* so check what we get back.<b= r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*/<br>- =C2=A0 =C2=A0 =C2=A0 if ((id-&g= t;key->flags & SSHKEY_FLAG_EXT) !=3D 0 &&<br>+ =C2=A0 =C2=A0= =C2=A0 if (id->key !=3D NULL && (id->key->flags & SSH= KEY_FLAG_EXT) !=3D 0 &&<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (r =3D sshkey_check_sigtype(*sigp, *lenp, alg)) !=3D 0) {<br>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 debug_fr(r, "sshkey_chec= k_sigtype");<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 goto out;<br><br>-- System Information:<br>Debian Release: 14 (forky)<b= r>Architecture: amd64<br>Kernel: 6.19.11+deb14-amd64</p><p><br></p><p><br><= /p><p>Cheer Alejandro</p></div> --000000000000bb9635065033a2ba-- ------------=_1783365662-1772484-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 1134814-close) by bugs.debian.org; 6 Jul 2026 19:19:29 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-114.1 required=4.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOURLA, FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,MD5_SHA1_SUM,PGPSIGNATURE, USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 172; hammy, 150; neutral, 530; spammy, 0. spammytokens: hammytokens:0.000-+--HX-Debian:DAK, 0.000-+--H*rp:D*ftp-master.debian.org, 0.000-+--HX-DAK:process-upload, 0.000-+--UD:debian.tar.xz, 0.000-+--H*r:sk:fasolo. Return-path: <[email protected]> Received: from muffat.debian.org ([2607:f8f0:614:1::1274:33]:43092) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <[email protected]>) id 1wgoqn-007Qw6-0z for [email protected]; Mon, 06 Jul 2026 19:19:29 +0000 Received: via submission from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=fasolo.debian.org,[email protected] (verified) by muffat.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <[email protected]>) id 1wgoqn-002FBd-2c for [email protected]; Mon, 06 Jul 2026 19:19:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ftp-master.debian.org; s=smtpauto.fasolo; h=Date:Message-Id:Content-Type: Subject:MIME-Version:To:Reply-To:From:Cc:Content-Transfer-Encoding:Content-ID :Content-Description:In-Reply-To:References; bh=GvyKVN7ysWrvLPOBNmLj3tcxg8f1R3TKtZykPGg5RKU=; b=CF4sU6+oi3Oh7eVkhe1DS98pas 2FagcJHRye+1UXL6ROoShpnoustOziP0bezbgewP/4x8NLlvhrcI7PZcCBuGLTPrjTqDzglOCCUkJ XdMByICBQmyTKeweTWZTxAZ3jeaAcBm6tdDyDslOgMMyHsFXuio68liB4aNv4MuEoCdbM9OT8cOff OXF2D7F7ddBISPoaFoGOQ21FKkl4UkxRcjYisIwZF+/E3xBmpz1sp5P23iIxeix8/BP3hGHaLazUf mNXmXt8IebR62ErKgooKz8RtlVekvGgU6HEFo3keodryF5T4m5RFPq0qfX/RqDYdjYKGjqMeABP4Y EdWp5jiw==; Received: from dak by fasolo.debian.org with local (Exim 4.98.2) (envelope-from <[email protected]>) id 1wgoql-00000002KbK-2Vzg; Mon, 06 Jul 2026 19:19:27 +0000 From: Debian FTP Masters <[email protected]> Reply-To: Colin Watson <[email protected]> To: [email protected] X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: openssh Debian: DAK Debian-Changes: openssh_10.4p1-1_source.changes Debian-Source: openssh Debian-Version: 1:10.4p1-1 Debian-Architecture: source Debian-Suite: unstable Debian-Archive-Action: accept MIME-Version: 1.0 Subject: Bug#1134814: fixed in openssh 1:10.4p1-1 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="===============4376018905883848518==" Message-Id: <[email protected]> Date: Mon, 06 Jul 2026 19:19:27 +0000 --===============4376018905883848518== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Source: openssh Source-Version: 1:10.4p1-1 Done: Colin Watson <[email protected]> We believe that the bug you reported is fixed in the latest version of openssh, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Colin Watson <[email protected]> (supplier of updated openssh package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [email protected]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Mon, 06 Jul 2026 19:11:28 +0100 Source: openssh Architecture: source Version: 1:10.4p1-1 Distribution: unstable Urgency: medium Maintainer: Debian OpenSSH Maintainers <[email protected]> Changed-By: Colin Watson <[email protected]> Closes: 1134814 1141420 Changes: openssh (1:10.4p1-1) unstable; urgency=3Dmedium . [ Sven Joachim ] * Make doc symlinks relative on upgrade from 1:10.3p1-5 (closes: #1141420). . [ Colin Watson ] * New upstream release: - SECURITY: sftp(1): when downloading files on the command-line using "sftp host:/path .", a malicious server could cause the file to be downloaded to an unexpected location. This issue was identified by the Swival Security Scanner. - SECURITY: scp(1): when copying files between two remote destinations, do not allow a malicious server to write files to the parent directory of the intended target directory. This issue was identified by the Swival Security Scanner. - SECURITY: sshd(8): when using the "internal-sftp" SFTP server implementation (this is not the default), long command lines were previously truncated silently after the 9th argument. If a security-relevant option was in the 10th or later position, it would be discarded. Reported by Steve Caffrey. - SECURITY: sshd(8): add a documentation note to mention that the GSSAPIStrictAcceptorCheck option is ineffective when the server is joined to a Windows Active Directory. Reported by Yarin Aharoni of Safebreach. - SECURITY: sshd(8): DisableForwarding=3Dyes didn't override PermitTunnel=3Dyes as it was documented to do. Note that PermitTunnel = is not enabled by default. Reported independently by Huzaifa Sidhpurwala of Redhat and Marko Jevtic. - SECURITY: sshd(8): avoid a potential pre-authentication denial of service when GSSAPIAuthentication was enabled (this feature is off by default). This was not mitigated by MaxAuthTries, but would be penalised by PerSourcePenalties. This was reported by Manfred Kaiser of the milCERT AT (Austrian Ministry of Defence). - SECURITY: sshd(8): fix a number of cases where the minimum authentication delay was not being enforced. Reported by the Orange Cyberdefense Vulnerability Team. - SECURITY: ssh(1): fix a possible client-side use-after-free if the server changes its host key during a key reexchange. This was reported by Zhenpeng (Leo) Lin of Depthfirst. - All: add experimental support for a composite post-quantum signature scheme that combines ML-DSA 44 and Ed25519 as specified in draft-miller-sshm-mldsa44-ed25519-composite-sigs. This scheme is not enabled by default. To use it, you'll need to add it to HostKeyAlgorithms, PubkeyAcceptedAlgorithms, etc. Keys may be generated using "ssh-keygen -t mldsa44-ed25519". - ssh(1), sshd(8): replace the wildcard pattern matcher with an implementation based on an NFA. This avoids exponential worst-case behaviour for the old implementation. - ssh-agent(1): fix incorrect reply to "query" SSH_AGENTC_EXTENSION requests. - sshd(8): avoid sending observably different messages for valid vs invalid users in GSSAPIAuthentication (disabled by default). - ssh(1), sshd(8): fix several bugs that incorrectly classified bulk traffic as interactive. - ssh-keygen(1), ssh-add(1): skip unsupported key types when downloading resident keys from a FIDO token. Previously, downloads would abort when one was encountered. - ssh(1): fix a potential use-after-free on an error path if cipher_init() fails. - sshd(8): perform stricter encoding and validation of transport state passed between sshd privilege separation subprocesses. This somewhat further hardens the server against attacks on sshd-auth or sshd-session subprocesses. - ssh-agent(1): avoid possible runtime denial of service by enforcing some limits on the length of usernames in key use constraints. - sftp(1): fix two separate one-byte out-of-bounds reads, in SSH2_FXP_REALPATH and batch command processing. - sftp-server(8): disallow use of the copy-data extension to read and write to the same inode simultaneously. - ssh(1), sshd(8): avoid strlen(NULL) crash if an X11 channel was created before the x11-req SSH_MSG_CHANNEL_REQUEST was sent. - sftp(1), scp(1): avoid a situation where sftp_download() could get stuck in a loop if a broken server repeatedly returned zero length while reading a file. - ssh(1): avoid leaking DNS0x20 case-randomised names into names canonicalised using CanonicalizePermittedCNAMEs. - sftp-server(8): avoid truncation of pathnames passed to lstat() during SSH_FXP_REALPATH handling on systems where PATH_MAX is not the actual max. - ssh(1), sshd(8): correct arming of poll(2) event masks for some socket-type channels. - sshd(8): major refactor of sshd_config parsing and management code, to allow for more exact serialisation/deserialisation across privilege separation boundaries. - ssh-add(1): open connection to the agent only after getopt() processing has completed, to give options like "-v" a chance to display debug information about this operation. - sshd(8): differentiate between execution failures and a subsystem that was not found when logging why a subsystem failed to start. - All: use safer idioms for timegm(3) and mktime(3) error detection. - ssh(1), sshd(8): avoid accepting invalid cipher or MAC lists in config files or command-line arguments. This could cause runtime failures later. - ssh(1): fix NULL deref crash during pubkey auth when using a PEM style private key with no corresponding .pub key adjacent to it (closes: #1134814). - sshd(8): don't print an error message when trying to load a host private key when PKCS#11 keys are in use, as these don't need the private half on the filesystem. - All: don't use deprecated ERR_load_crypto_strings(). - ssh(1): properly report errors during configuration default setting. - ssh(1): use correct directive name (Match instead of Host) in error message. - sftp(1): fix "ls -ln" which was not correctly showing numeric UID/GIDs but rather user and group names. - sshd(8): avoid possible NULL dereference if an allocation fails during config parsing. - All: fix ineffective guards against loading overly large public keys in several places. - sftp(1): ensure file descriptors used by sftp to communicate to its ssh(1) subprocess don't leak into executed subprocesses (e.g. via "!"). - Sync fmt_scaled.c with OpenBSD upstream, picking up an exactness fix for large exponents. - sshd(8): remove duplicate sandbox entry for clock_gettime64. - Sync getrrsetbyname.c with OpenBSD upstream, picking up robustness fixes. - Fix a number of memory leaks on error paths in the portability code. - Revise the README.privsep documentation to reflect sshd's recent switch to a multi-binary model. Checksums-Sha1: df9f47c0f27ac289f28a014382b376c751b36030 3651 openssh_10.4p1-1.dsc ae8650a71cc52dbbd049519cee276ae6d65c2c4d 2321796 openssh_10.4p1.orig.tar.gz 024bbb98d37dc35c31a49144770c6e38bfe53829 833 openssh_10.4p1.orig.tar.gz.asc eba70bbacbe02995f7eeec31a1dd96a7cd7a8058 208228 openssh_10.4p1-1.debian.tar.= xz Checksums-Sha256: 878de8e50995ae6a2eaad52c829036729c48a57a104d9ba32d558fb82096ee5e 3651 openss= h_10.4p1-1.dsc ef6026dd2aea8d56059638d5d3262902c892ceba9f88395835e0d06d3fb63238 2321796 ope= nssh_10.4p1.orig.tar.gz 9206329419c45245913ae42fd290e2ed5b1669df97d9cf0d3e28c06b63035e51 833 openssh= _10.4p1.orig.tar.gz.asc 5c5d2f7ee53bef6f96355eab24062b82f226ead501dc3f8630f75202f662ca1f 208228 open= ssh_10.4p1-1.debian.tar.xz Files: e89a2b713609f72642c98c6a454c45e1 3651 net standard openssh_10.4p1-1.dsc c5fb91ded926b38e8956074cac2cd44f 2321796 net standard openssh_10.4p1.orig.ta= r.gz 105ff131214dc93a4892488bc80b444a 833 net standard openssh_10.4p1.orig.tar.gz= .asc c9d6a49c9f1d34a9b0358f3860a9f1b2 208228 net standard openssh_10.4p1-1.debian= .tar.xz -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAmpL+hEACgkQOTWH2X2G UAtBwBAAhHqb1L4vbgAc1c0LGWm+Ebx6zyCgxVhwa6kHyy/+L2NtUmPIpwSlmIdw TIbpnKfqVXgvvykMHqXQQOU8fWWt4Q715m4UGv6F0NgDNr7RKicND6DfIlDXdzCp dwNZFLkqLMIrn8+DzYoNcMN2nN1q62jQ+cVc4q13UvK4uUrxQSGrdAb6dr3zaoMR /Exj6aPD++Tf5JoOt+BDnqRln/hjhsqnN3NqJ1000PaRi4JzP0YmZOz1/40Ja0dm yQ6Xo6bg+hasGcMa4GYXdFXFqI6mVRGItZ1CZgCCG9kfvDtXnSzgCC3no7BgW0bU Iyt5EVlauSiEEePOnn+I9FK+PDmfL6n4CmV2/DM2btbpjFO9g3FjUGRADDA5H6Fo wE5cEmISiRKO28qjAFyNDpSDqzN1GDE9RKMCf/l5lZLetMl3/8rfkwDRD1L/A5qb 9tz1NyycIH4Qlpv7++WUXzFxLJyQptrGD6Fj6uPdC6mmCAeeo6yy6DwAm5NxtntG nD2CH8zzHxJ0oLY/6sM8cgEvNfuok6tCNdHeyLUpI8DZXi3tzJToH92yd7uzLt3m pMM/BY/t05GZ3HabhxOCJi7H/OOk1MwNaDtlJnG1AOkwuYXXUDmwbPGYvXiDjsC5 uJ9SE+LmTcrZ8a/ms24nuf38GPta4mLTDY5OHBUNk6Ixj707nRo=3D =3DLnvT -----END PGP SIGNATURE----- --===============4376018905883848518== Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTziqJOuF8J+ZI8pJSb9qggYcy5IQUCakv/vwAKCRCb9qggYcy5 IQL6AP9vM3Eo6T/m9ETX8ycLdu+xYRaCrRRLq3z6wBxbmaWBIAEA3sgPebDtToI3 NB9euKqHDlVxDNQd4YyP3CRwOWm2eQE= =h5Pj -----END PGP SIGNATURE----- --===============4376018905883848518==-- ------------=_1783365662-1772484-0--