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: [email protected], Debian Security Team > > <[email protected]> > > > > 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
