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

As a general rule of thumb we do our best not to break binary compat.

I dont think that even regex plugins need to mess with this structure,
anything that does should be using the apis for it, so it should be fine. I
think.

Yves

On Mon, 31 Aug 2026 at 02:53, River Sierra via perl5-porters <
[email protected]> wrote:

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

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"