Source: golang-go.crypto Version: 1:0.50.0-1 Severity: grave Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for golang-go.crypto. I make it RC as the update to 0.52.0 upstream owuld cover a substantial set of CVEs to be fixed for forky. CVE-2026-39827[0]: | An authenticated SSH client that repeatedly opened channels which | were rejected by the server caused unbounded memory growth, | eventually crashing the server process and affecting all connected | users. Rejected channels are now properly removed from the | connection's internal state and released for garbage collection. CVE-2026-39828[1]: | When an SSH server authentication callback returned | PartialSuccessError with non-nil Permissions, those permissions were | silently discarded, potentially dropping certificate restrictions | such as force-command after a second factor succeeded. Returning | non-nil Permissions with PartialSuccessError now results in a | connection error. CVE-2026-39829[2]: | The RSA and DSA public key parsers did not enforce size limits on | key parameters. A crafted public key with an excessively large | modulus or DSA parameter could cause several minutes of CPU | consumption during signature verification. This could be triggered | by unauthenticated clients during public key authentication. RSA | moduli are now limited to 8192 bits, and DSA parameters are | validated per FIPS 186-2. CVE-2026-39830[3]: | A malicious SSH peer could send unsolicited global request responses | to fill an internal buffer, blocking the connection's read loop. The | blocked goroutine could not be released by calling Close(), | resulting in a resource leak per connection. Unsolicited global | responses are now discarded. CVE-2026-39831[4]: | The Verify() method for FIDO/U2F security key types (sk-ecdsa- | [email protected], [email protected]) did not check | the User Presence flag. Signatures generated without physical touch | were accepted, allowing unattended use of a hardware security key. | To restore the previous behavior, return a "no-touch-required" | extension in Permissions.Extensions from PublicKeyCallback. CVE-2026-39832[5]: | When adding a key to a remote agent constraint extensions such as | [email protected] were not serialized in the | request. Destination restrictions were silently stripped when | forwarding keys, allowing unrestricted use of the key on the remote | host. The client now serializes all constraint extensions. | Additionally, the in-memory keyring returned by NewKeyring() now | rejects keys with unsupported constraint extensions instead of | silently ignoring them. CVE-2026-39833[6]: | The in-memory keyring returned by NewKeyring() silently accepted | keys with the ConfirmBeforeUse constraint but never enforced it. The | key would sign without any confirmation prompt, with no indication | to the caller that the constraint was not in effect. NewKeyring() | now returns an error when unsupported constraints are requested. CVE-2026-39834[7]: | When writing data larger than 4GB in a single Write call on an SSH | channel, an integer overflow in the internal payload size | calculation caused the write loop to spin indefinitely, sending | empty packets without making progress. The size comparison now uses | int64 to prevent truncation. CVE-2026-39835[8]: | SSH servers which use CertChecker as a public key callback without | setting IsUserAuthority or IsHostAuthority could be caused to panic | by a client presenting a certificate. CertChecker now returns an | error instead of panicking when these callbacks are nil. CVE-2026-42508[9]: | Previously, a revoked 'SignatureKey' belonging to a CA was not | correctly checked for revocation. Now, both the 'key' and | 'key.SignatureKey' are checked for @revoked. CVE-2026-46595[10]: | Previously, CVE-2024-45337 fixed an authorization bypass for misused | ssh server configurations; if any other type of callback is passed | other than public key, then the source-address validation would be | skipped. CVE-2026-46597[11]: | An incorrectly placed cast from bytes to int allowed for server-side | panic in the AES-GCM packet decoder for well-crafted inputs. CVE-2026-46598[12]: | For certain crafted inputs, a 'ed25519.PrivateKey' was created by | casting malformed wire bytes, leading to a panic when used. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-39827 https://www.cve.org/CVERecord?id=CVE-2026-39827 [1] https://security-tracker.debian.org/tracker/CVE-2026-39828 https://www.cve.org/CVERecord?id=CVE-2026-39828 [2] https://security-tracker.debian.org/tracker/CVE-2026-39829 https://www.cve.org/CVERecord?id=CVE-2026-39829 [3] https://security-tracker.debian.org/tracker/CVE-2026-39830 https://www.cve.org/CVERecord?id=CVE-2026-39830 [4] https://security-tracker.debian.org/tracker/CVE-2026-39831 https://www.cve.org/CVERecord?id=CVE-2026-39831 [5] https://security-tracker.debian.org/tracker/CVE-2026-39832 https://www.cve.org/CVERecord?id=CVE-2026-39832 [6] https://security-tracker.debian.org/tracker/CVE-2026-39833 https://www.cve.org/CVERecord?id=CVE-2026-39833 [7] https://security-tracker.debian.org/tracker/CVE-2026-39834 https://www.cve.org/CVERecord?id=CVE-2026-39834 [8] https://security-tracker.debian.org/tracker/CVE-2026-39835 https://www.cve.org/CVERecord?id=CVE-2026-39835 [9] https://security-tracker.debian.org/tracker/CVE-2026-42508 https://www.cve.org/CVERecord?id=CVE-2026-42508 [10] https://security-tracker.debian.org/tracker/CVE-2026-46595 https://www.cve.org/CVERecord?id=CVE-2026-46595 [11] https://security-tracker.debian.org/tracker/CVE-2026-46597 https://www.cve.org/CVERecord?id=CVE-2026-46597 [12] https://security-tracker.debian.org/tracker/CVE-2026-46598 https://www.cve.org/CVERecord?id=CVE-2026-46598 [13] https://www.openwall.com/lists/oss-security/2026/05/22/6 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
