Perl 5.29.6 clarifies an earlier regex security fix

The release that documents a vulnerability is not always the release that first repairs it. Perl 5.29.6 makes that distinction explicit for CVE-2018-18312. Its release notes describe a crafted-pattern heap-buffer write during regular-expression compilation, with potential arbitrary code execution. They also state that the development branch fixed the problem in 5.29.4, where it was not announced as a security fix.

The history included with this release dates 5.29.6 to December 18. Its security section supplies information needed to interpret the earlier release. Calling December the first availability of the repaired development compiler would misstate that chronology. The announcement and the implementation change answer different questions.

I value a release note that makes this distinction plainly. Perl is useful to me partly because short programs can rely on powerful built-in text operations. Understanding which interpreter contains a repair should not require guessing whether the first visible CVE heading coincides with the first corrected code.

Compilation is already part of handling a pattern

The named function is S_regatom in regcomp.c. The triggering input is a crafted regular expression, and the reported memory write occurs while compiling it. A program accepting pattern syntax performs that compilation before obtaining a match result. The security description therefore concerns the pattern input, without establishing that arbitrary subject text alone triggers the same flaw.

The possible impact also needs its qualification. The notes say the heap write could potentially allow arbitrary code execution. They do not describe a demonstrated exploit against every application that uses regular expressions. Preserving that scope communicates the seriousness of memory corruption without inventing an application-specific attack.

The 5.28.1 maintenance notes also identify CVE-2018-18312 as a security fix. This provides a second release context for the same vulnerability. A stable maintenance release and a development release can document the same repair on different schedules, so comparing their version numbers without identifying the release line can confuse the question of availability.

The December clarification resolves that question for the development sequence. Its statement that 5.29.4 already contains the fix is more precise than assuming 5.29.6 introduced it merely because the security heading appears there. That is useful information for inventories that track interpreter releases, even before considering whether a particular application accepts external pattern syntax.

The repetition-limit description also changes

The errata section corrects another claim about 5.29.4. It says the explicit upper count n in {m,n} doubled to 65,534. The earlier release description instead said the maximum number of pattern matches doubled to 65,535. The correction distinguishes a finite count in pattern syntax from an unbounded quantifier.

The errata explicitly says the meaning of {m,} remains unchanged. It describes the unbounded form as matching up to 2**31 - 1 times on most platforms, with a platform qualification for wider C short integers. A larger finite count limit does not imply a corresponding change to every repetition form.

That difference matters to generated patterns. A generator emitting a finite upper bound needs the limit for its numeric syntax. A programmer choosing an unbounded form is requesting a different matching condition. Merging those cases in a release summary can lead a reader to choose the wrong number or misunderstand why a pattern compiles.

I consider these errata part of the technical value of the release. They revise the description of existing behaviour rather than adding another operator. Correcting a boundary value and the category of quantifier it applies to gives readers information they can use when constructing an expression.

In-place editing receives a completion rule

The release also defines a case in the safer in-place editing implementation. If editing is still in progress during global destruction and the process exit status stored in $? is zero, Perl treats the edit as successful and replaces the input with the output produced. The notes contrast leaving the processing loop with last against ending it with die.

This matters because a program can stop reading before reaching the ordinary end of input while still having produced its intended output. Completion cannot depend only on consuming every record. The repair uses the documented process status condition to decide whether to commit the edit during destruction.

A separate fix repairs a pipe after standard input has been closed. The notes say the child standard input could otherwise remain closed on exec, a regression introduced in 5.28. These changes concern the interpreter behaviour beneath compact file-processing programs. Together with the security chronology and quantifier errata, they make the release useful both for corrected execution and for a more accurate account of behaviour already shipped.