Post on oss-security: https://marc.info/?l=oss-security&m=165657063921408&w=2 Partial quote: """ After discovering that gpgv does not support --exit-on-status-write-error, I decided to check if it handles write errors on the status file descriptor properly. I ultimately found that while such errors are *not* handled properly, exploiting this flaw in practice would likely be very difficult and unreliable. However, in the course of this research (and entirely accidentally), I found that if a signature has a notation with a value of 8192 spaces, gpg will crash while writing the notation's value to the status FD. This turned out to be a far more severe flaw, with consequences including the ability to make a signature that will appear to be ultimately valid and made by a key with any fingerprint one wishes. """
*** Bug 2103715 has been marked as a duplicate of this bug. ***
Created gnupg1 tracking bugs for this issue: Affects: epel-all [bug 2108444] Affects: fedora-all [bug 2108445] Created gnupg2 tracking bugs for this issue: Affects: fedora-all [bug 2108443]
FYI I can reproduce this using gpg2 and the examples in the email, but not with gpg1 due an unsupported algorithm in the signature. It looks like this is possible with a supported gpg1 signature, so I'm going to backport Werner's fix to g10/status.c which is where that code lives in the gpg1 codebase.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:6463 https://access.redhat.com/errata/RHSA-2022:6463
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:6602 https://access.redhat.com/errata/RHSA-2022:6602
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2022-34903