Perl 5.28.1 repairs environment allocation and regex compilation

Calculating a buffer size is part of input handling. Perl 5.28.1 fixes a case where the combined length of an environment-variable name and value could overflow integer arithmetic before allocation. The release notes describe CVE-2018-18311 as a route to writing attacker-supplied data beyond an allocated buffer when that combined length exceeded approximately 0x7fffffff. The failure concerns the interpreter operation that constructs an environment entry.

The same release fixes CVE-2018-18312, a heap-buffer write during compilation of a crafted regular expression that could potentially permit arbitrary code execution. These are separate triggers in separate parts of the interpreter. The tagged history dates 5.28.1 to November 29, and the notes state that it introduces no intentionally incompatible changes from 5.28.0.

I consider this maintenance work relevant even when Perl is being used for a small text task. A program can delegate substantial work to built-in operations without expressing any memory allocation itself. Keeping that convenience requires the interpreter to reject or handle sizes that its internal arithmetic cannot safely represent.

Constructing an environment entry

The implementation in util.c shows the allocation problem concretely. Its formatting macro copies the name, adds an equals sign, copies the value, and appends a terminating zero byte. Allocation therefore has to account for the name and value lengths plus two bytes. Reserving space for only the payload strings would already be insufficient, even before considering arithmetic wraparound.

The repaired implementation uses a helper called S_env_alloc. It accepts component lengths and an element size, adds the lengths, and checks for wraparound as it constructs the allocation size. On the error path it calls croak_memory_wrap. It then uses allocation or reallocation according to whether an existing pointer was supplied.

In the entry-construction path, the call passes the name length, value length, and two extra bytes with an element size of one. That directly corresponds to the formatting operation. Size types in this path are Size_t, so the code ties the stored lengths to the allocation calculation instead of relying on the narrower arithmetic described by the vulnerability.

The helper also appears where the interpreter allocates or expands its environment pointer array. That is a related but distinct allocation, involving the number of pointers and their element size. Sharing the checked allocation helper gives those paths a common way to reject an unusable computed size.

The implementation has several environment-handling branches because the available system interfaces differ. Some manipulate the environment array, while others call functions such as putenv. The source shows the same name-and-value construction in more than one branch. Correcting a single visible assignment in an application would not describe the full interpreter repair.

The approximate length in the advisory should also remain approximate in an explanation. It identifies the scale at which the vulnerable arithmetic could wrap. It does not establish that every application accepts environment data of that size or that every host reaches the same failure through identical system calls. The documented risk is the unchecked arithmetic and resulting out-of-bounds write.

A pattern can fail before matching starts

CVE-2018-18312 concerns compilation in S_regatom, in regcomp.c. The notes describe a crafted regular expression as the trigger. This is relevant to applications that construct or accept pattern syntax, since compiling that syntax is already interpreter work. A fixed pattern operating on external subject text presents a different input relationship.

The notes identify potential arbitrary code execution, so this is more serious than rejecting a malformed pattern with an ordinary exception. They do not provide a complete exploit chain or claim that every use of regular expressions permits code execution. Preserving the distinction between potential impact and a demonstrated application-level attack is necessary to explain the repair accurately.

The two CVEs consequently call for different questions about inputs. One concerns lengths used to construct an environment entry. The other concerns the contents of a compiled pattern. Neither can be reduced to a generic problem with long matched strings, and the release does not present them that way.

Script runs must distinguish digit sets

A separate correctness fix affects script-run patterns introduced in Perl 5.28. The notes give a string containing ASCII 1 followed by THAI DIGIT FIVE that incorrectly matched a script-run expression for decimal digits. The repaired matcher rejects that combination. This changes a specific result of the matching operation, independently of the memory-write vulnerability in compilation.

The script-run documentation describes an additional criterion applied after the enclosed pattern matches. The text must satisfy the script-run requirements, or the engine backtracks to find another suitable match. This construct therefore adds a condition beyond a sequence merely satisfying \d+ or another enclosed expression.

That mechanism explains why the digit bug matters. Accepting each character as a decimal digit is insufficient when the enclosing construct also promises the required compatibility of the digit sequence. The fix makes the example obey that additional condition. It does not replace the script-run rules with a requirement that every accepted character have one simple script label in every case.

I find this a useful example of why a maintenance release can contain both security and semantic corrections to one broad facility. A regex compiler must manage memory safely, and a matcher must enforce the condition a construct advertises. Perl 5.28.1 addresses both, while also fixing a directory-handle leak in the new in-place editing code and a spurious smartmatch warning associated with an index optimization. Those are focused corrections to existing behaviour within the stable release line.

The compatibility statement gives users a specific expectation for this patch release. Existing valid programs should retain their intended interfaces while the interpreter repairs the faulty allocation and matching cases. A behaviour change caused by rejecting the previously incorrect digit combination follows from enforcing the documented script-run condition.