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

rouca

Hi,

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).

Cheers,
Charles

[1] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.7.9-2&stamp=1681563287&raw=0
[2] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.8.13-1&stamp=1777616480&raw=0
[3] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.8.9-3&stamp=1752060908&raw=0
[4] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.7.1-5%2Bdeb11u10&stamp=1779462994&raw=0
[5] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.6.7-4&stamp=1560369034&raw=0
[6] https://buildd.debian.org/status/fetch.php?pkg=gnutls28&arch=amd64&ver=3.5.8-5&stamp=1488914954&raw=0

HI Charles,
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

Le mardi 11 août 2026, 07:57:30 heure d’été d’Europe centrale Salvatore Bonaccorso a écrit :

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

Control: severity -1 normal
[...]

Hello Bastian,

if you can find the time feel free to report upstream, if not please tell
me.

I have verified that we indeed do not (accidentally) use the embedded
copy. The respective c-files are not compiled.

While doing that I found a minor issue though, libgnutls-dane uses the
.h-files from minitasn. https://gitlab.com/gnutls/gnutls/-/work_items/1931

cu Andreas

Le mardi 11 août 2026, 19:14:49 heure d’été d’Europe centrale Andreas Metzler a écrit :

Thanks

That why i believe vendoring is bad.

Could I add this issue to a wiki for rembering ?

I will report upstream.

rouca

On 2026-08-11 Bastien Roucaries <rouca@debian.org> wrote:
[...]

Thanks. Let's close this report here.

cu Andreas