Bug#1144080: gnutls28: mismege of CVE-2025-13151

[Salvatore Bonaccorso]

HI Charles,

On Tue, Aug 11, 2026 at 01:52:05AM -0300, Carlos Henrique Lima Melara wrote:
> Hi,
> 
> On Mon, Aug 10, 2026 at 09:55:46PM +0200, Bastien Roucaries wrote:
> > 
> > CVE-2025-13151 (libtasn1 - off-by-one in asn1_expand_octet_string, fixed in
> > 4.20.0)
> > 
> >  The fix changes:
> >    char name[2 * ASN1_MAX_NAME_SIZE + 1]
> > 
> >  to:
> >    char name[2 * ASN1_MAX_NAME_SIZE + 2]
> > 
> >  This applies to two functions: asn1_expand_any_defined_by and
> >  asn1_expand_octet_string.
> > 
> > gnutls28 vendor libtasn1 internally and show a partial fix -
> > asn1_expand_any_defined_by has been updated (+ 2 present) but
> > 
> > asn1_expand_octet_string still carries the vulnerable version (+ 1):
> >    - gnutls28 (lib/minitasn1/decoding.c)
> > 
> >      asn1_expand_any_defined_by: patched
> >      asn1_expand_octet_string: VULNERABLE
> > 
> > Thanks Gajendra Nath Soren
> 
> bullseye/bookworm are also affected in asn1_expand_octet_string and
> buster/stretch are affected in both asn1_expand_octet_string and
> asn1_expand_any_defined_by.
> 
> I don't know exactly how to deal with this case of embedded code copies
> in the security-tracker so, secteam, could you assist here? (do we just
> mark gnutls28 as affected by CVE-2025-13151?)
> 
> Although it has the minitasn1 code embedded, I don't think it's being
> used. Looking closer, the configure script is using the distro version
> [1]:
> 
> checking for libtasn1 >= 4.9... yes
> checking whether to use the included minitasn1... no
> 
> Same goes for sid/forky [2], trixie [3], bookworm [1], bullseye [4],
> buster[5] and stretch [6]. So I think this is a case where the
> vulnerability is only in the source code and not in the built binary
> (provided libtasn1 shared library has been updated with the fix).

Generally: If the embedded source is not used at all it has no
security impact, so our usual approach here is to not even list
src:gnutsl28 in the respective CVE entry for the libtasn1-6 issue.  If
an embedded source OTOH is used and has a security impact on the
embedding source, then it can/should be listed.

So I guess #1144080 can be closed (or if Andreas wants to track the
update to the embeded copy then RC level is defintively not warranted,
and the bug can be downgraded to minor and then closed once the
embedded copy is updated upstream to include the fix. But TBH I do not
think this overhead is needed here).

Regards,
Salvatore