Audit an old Perl installation against the 5.24.3 fixes

You will determine whether a Perl installation is in the 5.24.2 to 5.24.3 upgrade gap, record the interpreter you actually run, and identify the security fixes that make the upgrade relevant. Allow about ten minutes. The checks are read-only and normally need no elevated privileges.

perl5243delta is a release note, not an upgrade command. It describes changes between Perl 5.24.2 and 5.24.3. The manual installed on this machine comes from perl-doc version 5.38.2-3.2ubuntu0.6, while the interpreter is Perl v5.38.2. That distinction matters: the presence of this historical document does not mean that the machine runs Perl 5.24.3.

1. Confirm which Perl you are auditing

Start with the executable found through your current PATH:

$ command -v perl
/usr/bin/perl
$ perl -e 'print "$^V\n"'
v5.38.2
$ perl -V:version
version='5.38.2';

The first command tells you which binary a normal shell invocation selects. The two Perl commands report the running interpreter, rather than the version of a package or a manual page. If your output is not v5.24.2, the narrow 5.24.2 to 5.24.3 comparison does not describe your exact installed version.

Checkpoint: save the full path and version in the change record for the host. If an application uses a version manager, container, shebang path or service-specific environment, repeat this check in that execution context. A system-wide /usr/bin/perl check cannot prove what a service runs.

2. Read the release boundary before looking at fixes

Ask the local manual for its opening sections:

$ man perl5243delta
$ man perl5242delta

The first page covers 5.24.2 to 5.24.3. If you are upgrading from 5.24.1, the manual explicitly directs you to read perl5242delta as well. Do not treat a single delta page as a complete audit across several releases.

The release notes say there were no intentionally incompatible changes between 5.24.2 and 5.24.3. That is useful for planning, but it is not a compatibility guarantee for an application: distribution patches, XS modules, configuration choices and later Perl releases can still affect behaviour.

3. Prioritise the security section

The most urgent items are three vulnerabilities fixed in 5.24.3:

• A heap buffer overflow could be triggered while compiling some case-insensitive regular expressions, identified as CVE-2017-12837.
• Some regular-expression syntax errors could read arbitrary memory or crash the interpreter, identified as CVE-2017-12883.
• A possible Windows stack buffer overflow in %ENV handling was removed, identified as CVE-2017-12814.

These are release-note statements about affected historical code. Do not try to reproduce a crash or feed untrusted patterns to an old interpreter merely to prove exposure. Check the version and obtain the supported package update through your normal distribution process.

Checkpoint: if the audited interpreter is 5.24.2 or older in the relevant 5.24 series, mark it for an update or compensating review. If it is 5.24.3 or later, continue checking the vendor's package security notices, because a later release may contain additional fixes.

4. Review changes that can affect tests

The page also records fixes that are useful when an upgrade changes test results or failure handling. Perl 5.24.3 corrected some crashes and parser assertions, made socket preserve the system error in $! on failure, fixed an off-by-one line number with -x, and reverted a platform-dependent change to fchown and negative one. It also fixed several hexadecimal floating-point printf "%a" issues.

Use these notes to choose regression tests, not as a list of commands to paste blindly. A small, safe smoke test can confirm which interpreter a test runner invokes:

$ perl -e 'print "perl=$^V\n"; print "regex=ok\n" if "Perl" =~ /perl/i; print "hexfloat=", sprintf("%a", 1.5), "\n"'
perl=v5.38.2
regex=ok
hexfloat=0x1.8p+0

This does not prove that every historical bug is fixed. It only verifies the selected interpreter, a regular-expression operation and the local implementation of hexadecimal floating-point formatting. Keep application-specific tests separate and compare their results before and after an approved package change.

5. Upgrade through the package owner

Do not replace /usr/bin/perl by hand or copy a binary over a distribution-managed file. On Debian or Ubuntu, inspect the package state first:

$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

Exact output varies with the distribution and update level. Use the distribution's normal update workflow, maintenance window and rollback plan. Package installation or system-wide Perl replacement requires elevated privileges and can affect services, so it is deliberately not included as a copy-and-paste command here. For a source build, read the matching INSTALL and test the application against the new interpreter before changing a service's shebang or unit.

After an approved update, repeat Step 1 in the same context as the application. If a service still reports the old version, inspect its executable path, environment and restart procedure rather than assuming the package update failed. Undo the change using your package manager's documented rollback or restore procedure; do not delete the old interpreter manually.

Common traps

• Confusing documentation with code: perl5243delta can be installed by perl-doc even when the interpreter is much newer.
• Checking the wrong context: your interactive shell, a cron job and a service may resolve different Perl binaries.
• Stopping at the first delta: upgrades across more than one release need each intervening delta and the vendor's advisories.
• Testing by exploiting: a crash experiment can harm a process and does not establish a safe production posture.
• Assuming a successful command is a security audit: the smoke test checks selection and basic behaviour, not vulnerability coverage.