|
|
Message-ID: <aXkblElCH4uYloI_@eldamar.lan>
Date: Tue, 27 Jan 2026 21:09:56 +0100
From: Salvatore Bonaccorso <carnil@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: GnuPG security release
Hi,
CVEs seems to have been assigned as follows:
On Tue, Jan 27, 2026 at 04:44:11PM +0000, Sam James wrote:
> GnuPG 2.5.17 has been released to fix a possible RCE:
> * https://dev.gnupg.org/T8044 ("gpg-agent stack buffer overflow in pkdecrypt using KEM")
>
> [Description for this one at the end, for the full quoted advisory.]
This is https://www.cve.org/CVERecord?id=CVE-2026-24881
> There's two other security-relevant bugs too:
> * https://dev.gnupg.org/T8045 ("Stack-based buffer overflow in TPM2 `PKDECRYPT`")
>
> > A stack-based buffer overflow exists in GnuPG’s tpm2daemon when handling
> > the PKDECRYPT command for TPM-backed RSA and ECC keys. A local attacker
> > who can access the daemon’s Assuan socket can send an oversized ciphertext
> > and trigger memory corruption, resulting in a crash and potentially
> > arbitrary code execution. When a user stores private keys inside a TPM,
> > GnuPG runs a helper process called tpm2daemon to perform cryptographic
> > operations on their behalf. Other GnuPG components communicate with this
> > daemon over Assuan, a local IPC protocol. During a PKDECRYPT request,
> > tpm2daemon copies the attacker-supplied ciphertext into fixed-size TPM
> > work buffers without validating that the ciphertext fits. If the supplied
> > ciphertext is larger than the TPM buffer, the copy operation writes past
> > the end of the stack buffer and corrupts adjacent stack memory. This
> > affects both supported TPM decrypt paths: RSA (tpm2_rsa_decrypt) and ECC
> > (tpm2_ecc_decrypt). Because the overflow occurs on the stack and is
> > attacker-controlled, it is potentially exploitable for code execution
> > inside the tpm2daemon process.
This is https://www.cve.org/CVERecord?id=CVE-2026-24882
>
> * https://dev.gnupg.org/T8049 ("Null pointer dereference with overlong
> signature packet")
>
> > Overlong signature packet length causes parse_signature to return
> > success with sig->data[] left NULL, leading to a crash in later
> > consumers.
This is https://www.cve.org/CVERecord?id=CVE-2026-24883
Regards,
Salvatore
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.