Bug#1144413: perl: CVE-2026-15534

[Salvatore Bonaccorso]

Hi Niko,

On Mon, Aug 17, 2026 at 10:40:12PM +0300, Niko Tyni wrote:
> Control: tag -1 moreinfo
> 
> On Fri, Aug 14, 2026 at 08:46:58PM +0200, Salvatore Bonaccorso wrote:
> > Source: perl
> > Version: 5.42.2-3
> > Severity: important
> > Tags: security upstream
> > X-Debbugs-Cc: carnil at debian.org, Debian Security Team <team at security.debian.org>
> > 
> > Hi,
> > 
> > The following vulnerability was published for perl.
> > 
> > Filling a bug for tracking the issue.
> > 
> > CVE-2026-15534[0]:
> > | Perl versions through 5.45.1 have out-of-bounds heap reads and
> > | writes during regular expression matching via an undersized
> > | superlinear cache in S_regmatch.  The regex engine's superlinear
> > | cache holds one bit per subject position for each participating
> > | WHILEM node, so the bit count is the subject length plus one times
> > | the number of nodes. Nothing checks that product for positive
> > | overflow of the signed 32-bit count: a 286331153 byte subject
> > | matched against a pattern with 15 participating nodes stores the
> > | count as 14, leaving a two byte cache. The cache is then indexed
> > | from the real match position and node number, so reads go past the
> > | end of the allocation, and on failure CACHEsayNO sets a bit past it.
> > | A caller that matches an attacker controlled subject of this size
> > | against a pattern of this shape can crash the process or corrupt
> > | heap memory.
> > 
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2026-15534
> >     https://www.cve.org/CVERecord?id=CVE-2026-15534
> > [1] https://lists.security.metacpan.org/cve-announce/msg/42536248/
> 
> Thanks Salvatore.
> 
> I don't see an upstream backport for 5.42 or 5.44 yet.
> 
> The suggested two patches are from the upstream development branch
> ("blead".) They apply cleanly to 5.42.3, but this hunk in the latter
> one looks to me like a possible ABI break on 64-bit architectures:
> 
>   https://github.com/Perl/perl5/commit/54cf3d44cbbedd17d774e9a37921963e8fd5d0cb
> 
>   diff --git a/regexp.h b/regexp.h
>   index 057d9ac5011b..d5d40e0a5618 100644
>   --- a/regexp.h
>   +++ b/regexp.h
>   @@ -839,8 +839,8 @@ typedef struct {
>        char *cutpoint;      /* (*COMMIT) position (if any) */
>        regmatch_info_aux      *info_aux; /* extra fields that need cleanup */
>        regmatch_info_aux_eval *info_aux_eval; /* extra saved state for (?{}) */
>   -    I32  poscache_maxiter; /* how many whilems todo before S-L cache kicks in */
>   -    I32  poscache_iter;    /* current countdown from _maxiter to zero */
>   +    STRLEN poscache_maxiter; /* how many whilems todo before S-L cache kicks in */
>   +    STRLEN poscache_iter;    /* current countdown from _maxiter to zero */
>        STRLEN poscache_size;  /* size of regmatch_info_aux.poscache */
>        bool intuit;    /* re_intuit_start() is the top-level caller */
>        bool is_utf8_pat;    /* regex is utf8 */
>   
> This is modifying struct regmatch_info in the public regexp.h header,
> growing two members from 32 bits to 64 bits on 64-bit architectures.
> 
> While the struct looks internal to Perl and there's nothing in Debian
> that uses the struct (not even libre-engine-re2-perl), it's nevertheless
> included in perlapi.pod which documents the public API. So I'd rather
> play it safe.
> 
> I just asked the perl5-porters list about this, and I'm not uploading
> it to sid for now.

Thanks for that!

(note, I was not aiming to get a quick fix in unstable, but start
tracking the issue in the BTS, a upstream "blessed" change for the
needed version is defintively what we should aim at, and a fix for
this issue can wait until then).

Regards,
Salvatore