Audit a Perl 5.24.4 Upgrade for Security and readpipe Changes

You will finish with a small, repeatable audit for Perl 5.24.4: identify the security fixes, check the interpreter you are actually running, and test the one documented behaviour change that can affect source code. Allow about fifteen minutes. This is an audit and verification guide, not an instruction to replace the Perl supplied by your operating system.

The installed manual describes the differences between Perl 5.24.3 and 5.24.4. On this machine, the manual comes from perl-doc version 5.38.2-3.2ubuntu0.6 and identifies itself as Perl 5.38.2. That matters: the document is historical release information, while the executable and package manager decide what is installed now.

1. Record the interpreter and documentation versions

Start with read-only checks. They need no elevated privileges:

$ command -v perl
/usr/bin/perl
$ perl -v | sed -n '1,4p'
This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc perl
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

On another distribution, use its package query tool instead. Do not infer the interpreter version from the name of a manual page: multiple Perl release notes can be installed together, and a versioned document does not select the runtime.

2. Read the security scope before changing anything

Perl 5.24.4 fixed three memory-safety issues and one crash condition listed by perl5244delta:

• A crafted regular expression could cause a heap buffer write overflow in S_regatom.
• A crafted locale-dependent regular expression could cause a heap buffer read overflow and possible information disclosure in Perl__byte_dump_string.
• pack() could cause a heap buffer write overflow with a large item count.
• Control characters in a supposed Unicode property name could trigger an assertion failure and crash Perl.

The first three are identified in the manual as CVE-2018-6797, CVE-2018-6798 and CVE-2018-6913. The practical result is not a new command-line flag. It is that an interpreter containing the fixes is safer to run when it processes regular expressions, locale data or large pack() inputs.

Do not try to reproduce these faults against a production interpreter. This guide does not provide exploit strings, and the manual's descriptions are enough to define the upgrade boundary. If you maintain a Perl 5.24 installation, compare its vendor package or build revision with the security advisory and schedule the normal tested upgrade path. Replacing a system Perl can break package tools and services, so do not overwrite /usr/bin/perl by hand.

3. Check the intentional compatibility statement

The release notes say there are no changes intentionally incompatible with Perl 5.24.3. That is useful for planning, but it is not a compatibility guarantee for every application. The same section asks users to report any incompatibility as a bug, which means an observed difference still needs a real test.

For an application upgrade, run its existing test suite with the candidate interpreter. Include tests that exercise regular expressions, locale-sensitive processing, packing and Unicode property handling. This is an ordinary application test and should run as the service user or your own account, not as root.

4. Test the readpipe fix with a harmless command

Perl 5.24.4 changed the built-in readpipe() function so it checks at compile time that it has only one parameter expression and puts that expression in scalar context. The change prevents a stack corruption problem at runtime. A short test confirms the normal, supported form:

$ perl -e 'my $out = readpipe("printf ready"); print "readpipe output: [$out]\n"'
readpipe output: [ready]

The command runs printf through the shell used by readpipe and captures its output as a scalar. The example is safe because the command string is fixed. Do not concatenate untrusted input into a shell command. If you need to execute a program with untrusted arguments, use a list-form process interface such as system LIST or a suitable Perl module instead.

Multiple parameter expressions are rejected during compilation. You can see the boundary without running an external command:

$ perl -e 'readpipe("printf one", "printf two")'
Too many arguments for quoted execution (`, qx) at -e line 1, near "printf two")
Execution of -e aborted due to compilation errors.

The exact diagnostic can vary slightly with the Perl release, but failure before execution is the important property. Do not 'fix' old code by adding a second expression. Make the command one deliberate expression, then pass data safely according to the program's interface.

5. Account for the module note

The release notes record Module::CoreList moving from version 5.20170922_24 to 5.20180414_24. This is a core module inventory update, not a request to install that version separately on every current system. Check the module only when your application or build tooling depends on its reported core-module data:

$ perl -MModule::CoreList -e 'print "$Module::CoreList::VERSION\n"'
5.20250920_38

Your result will differ on a newer Perl, and that is expected. The useful question is whether the interpreter and its bundled modules match the package or build you approved, not whether a current system reports the historical 5.24.4 number.

6. Finish without changing the host

There is nothing to undo in these checks: they only read metadata or run short child processes. If you installed a candidate Perl to test an application, remove it only through the same package or build system that installed it, and only after confirming which files and services depend on it. Do not delete a versioned Perl directory by guesswork.

For a bug report, the manual recommends a small test case and the output of perl -V. For a security-sensitive report, use the private contact process documented by perlsec rather than posting exploit details to a public list.