Perl 5.26.1 fixes memory errors while compiling regexes

Rejecting an invalid regex is still work that must respect memory boundaries. Perl 5.26.1 fixes a parser over-read in which certain syntax errors could produce diagnostics containing an arbitrary, possibly large chunk of memory. The same error path could crash the interpreter. Its release notes identify the problem as CVE-2017-12883. Alongside a separate regex compilation overflow, it makes this maintenance update relevant before a program ever reaches matching. The release history records September 22, 2017.

The distinction between compiling, reporting an error and matching matters for understanding the exposure. A program that accepts a pattern may exercise the compiler even if it never obtains a valid regex. An application that returns or logs the resulting error can also handle text produced by the faulty diagnostic path. Rejecting the pattern at that point does not undo memory that the interpreter has already read.

I value Perl's regex integration for short text-processing programs. These fixes are relevant to that strength because the language makes it easy to turn pattern text into executable matching behavior. The implementation needs a safe failure path as well as correct results for accepted patterns.

Compilation has a separate overflow

CVE-2017-12837 concerns a heap buffer overflow while compiling certain patterns with the case-insensitive modifier. The release notes state that it could crash Perl and that the release fixes it. This report is distinct from the error-message over-read, even though both involve preparing a regular expression.

A write beyond a heap buffer and a read beyond an intended region are different memory failures. In the former case, the compiler writes outside the storage allotted to its work. In the latter, diagnostic construction can expose bytes that do not belong to the intended error text. The two identifiers should remain separate when identifying which fixes an interpreter build includes.

The notes do not say that all case-insensitive regexes are affected. They describe certain patterns with that modifier. Nor do they provide a demonstrated remote exploit or a general severity calculation. The documented consequences support treating the compiler overflow as a security fix without extending the claim to outcomes the source does not establish.

This boundary also explains why a matching-only description is incomplete. A caller may fail while constructing the regex, before testing any target string. The dangerous input in the documented case is the pattern submitted to compilation. A reproduction concerned only with an ordinary match against hostile subject text would investigate a different route unless it also supplied the affected pattern.

Diagnostics can disclose process memory

For CVE-2017-12883, the failure occurs with particular types of syntax error. The output may include a random chunk of memory or the interpreter may crash. An error message is supposed to describe the rejected pattern, so incorporating unrelated memory violates the boundary between the user's input and the process's other data.

That matters for services that expose diagnostics to their callers. The release does not identify which other data will be present or promise that a particular secret can be recovered. Its description is broader and less deterministic. A possibly large arbitrary memory segment in an error is already an unwanted disclosure, regardless of whether a specific application stores credentials nearby.

Logging the error instead of returning it changes who receives the output, but does not make the over-read correct. The interpreter must restrict diagnostic construction to valid input and owned storage. The maintenance release fixes that implementation responsibility at its source, rather than asking every application to predict which malformed patterns can trigger it.

The Windows fix removes the buffer

A third security entry, CVE-2017-12814, addresses a possible stack buffer overflow in Windows %ENV handling. The notes describe the repair as removing the buffer completely because it was unnecessary. That is a useful implementation detail, because it distinguishes elimination of the storage from merely increasing its size.

The Windows qualification is important. It would be inaccurate to attach this particular %ENV stack-buffer report to every platform using Perl. The regex security entries and the platform-specific environment entry belong to the same release, but their documented conditions differ.

I prefer this kind of direct repair when the intermediate storage has no remaining purpose. Removing the buffer also removes the need to keep its capacity synchronized with inputs through that path. The source does not claim that all environment handling is now free of memory risks, and this one fix should not be described that way.

Maintenance preserves the language contract

The release states that it has no intentionally incompatible changes relative to 5.26.0. That compatibility policy matters for an existing installation considering these security corrections. The update is not presented as requiring adoption of a new set of language semantics to obtain the fixes.

The base module also advances to version 2.26. Its notes describe a more refined treatment of removing dot from @INC with fewer false positives. This addresses compatibility around the search-path change already present in 5.26.0. It is separate from the regex memory vulnerabilities and does not restore a general default search of the working directory.

Other corrections concern memory bookkeeping inside ordinary built-ins. Some functions wrote to the internal stack without allocating the needed space, which could cause rare crashes. The release fixes those cases and says debugging builds will automatically detect similar future mistakes. A list-assignment correction also initializes an entry that could previously be left uninitialized on the mortal stack.

The numeric conversion routine my_atof2 no longer reads beyond the terminating NUL when a decimal point appears immediately before it. Regex substitution on UTF-8 strings also receives a fix for occasional malformed-character crashes. These are concrete reasons for an application with no use of hostile pattern input to benefit from the maintenance update as well.

For interpreter and extension builders, the source records more platform-specific corrections. Windows gains support for Visual Studio 2017, and 64-bit Windows XS builds with GCC 6 receive corrected strtoll and strtoull mappings. Those entries make compiler and platform information relevant when distinguishing a build failure from the runtime memory errors repaired elsewhere in the release.