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

[Bastien Roucaries]

Le mardi 11 août 2026, 07:57:30 heure d’été d’Europe centrale Salvatore Bonaccorso a écrit :
> 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).

Please report upstream or coordinate with upstream here, or let me report upstream.

I was also burned a long time ago by embeded code copy that is compiled due to upstream change, so for lib it is interesting sometimes to
repack in order to avoid upstream change that get vendoring compiled by accident

thanks
> 
> Regards,
> Salvatore
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnutls-maint/attachments/20260811/cc7f8d0d/attachment.sig>