Re: CVE-2026-15534 and binary compatibility for Perl stable releases

On Monday, 17 August 2026 at 20:43, Niko Tyni <[email protected]> wrote:
> I'm looking at CVE-2026-15534 for Debian (currently still at Perl 5.42):
> 
>  https://lists.security.metacpan.org/cve-announce/msg/42536248/
> 
>   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.
> 
> This is recommending to apply the patches from
> 
>   https://github.com/Perl/perl5/commit/568e6fd238867bb9e99fa3f47cba3169009239e0
> 
>   https://github.com/Perl/perl5/commit/54cf3d44cbbedd17d774e9a37921963e8fd5d0cb
> 
> The patches apply cleanly on 5.42.3, but I'm somewhat worried about this
> hunk in the latter one:
> 
>   --- 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.
> Is there a risk of binary incompatibility issues here?
> 
> While the struct looks internal to Perl and there's no code in Debian
> that uses the struct (not even re-engine-RE2), it's nevertheless included
> in perlapi.pod as part of the public API. So I thought I'd check first.
> 
> Are there plans for maint-* backports of this? I don't see any at
> the moment.

I have desire for binary API compatibility between different 5.42.x versions of perl, and compiled packages.

That is to say, it would help me greatly if packages built using perl 5.42.x would work equivalently with perl 5.42.y (assuming that x and y were built using identical toolchains), with a specific focus on being able to use packages built using perl 5.42.3 with a possible future perl 5.42.4.

If the binary API between perl and compiled packages is to be incompatible between 5.42.x and 5.24.y, even if partially, it would help me if I could understand the nature of the breakage sooner rather than later.

I concede that I have neither proposed a solution nor proffered insight. I think for this initial message the value is to highlight that there may be multiple consumers who feel the same way.

Many thanks for your continuing hard work on Perl.

Regards,

River