Use perl5363delta to audit a Perl 5.36.3 upgrade

You will use perl5363delta as a short upgrade audit: identify the release range it covers, check the Perl interpreter and documentation installed on this Linux host, and decide whether the two documented security fixes are relevant to your deployment. Allow about fifteen minutes. You need a shell and the perl-doc package; reviewing the document is unprivileged.

1. Confirm what the document covers

Start by reading the installed manual page. The local copy is the primary source for this guide and is supplied by perl-doc:

$ man perl5363delta

The document describes differences between Perl 5.36.1 and Perl 5.36.3. It deliberately skips 5.36.2, which the document calls a broken release that existed briefly. If you are coming from 5.36.0, read perl5361delta as well; this page is not a complete 5.36 upgrade history.

You can locate the underlying pod file without opening a pager:

$ perldoc -l perl5363delta
/usr/share/perl/5.38/pod/perl5363delta.pod

Your path can differ. The useful result is a readable path and a matching manual entry. If perldoc cannot find it, install the documentation package through your distribution's approved package source. Do not copy a random pod file into /usr/share.

2. Record the interpreter version separately

The release named by a delta document and the interpreter actually running your application are different facts. Check both the human-readable version and the package version:

$ perl -v
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-base perl-doc
perl-base 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

These exact package values are host-specific. On another Debian-family system, the revision can differ; on an RPM-based system, use the package query tool provided by that distribution. The important comparison is whether the interpreter is in the vulnerable 5.30.0 through 5.38.0 range mentioned by the manual, or whether your distributor has backported a fix into a later package revision.

$ command -v perl
/usr/bin/perl
$ /usr/bin/perl -MConfig -e 'print "$Config{version}\n"'
5.38.2

3. Understand the security findings

Perl 5.36.3 fixes two issues described in the manual. CVE-2023-47038 is a one-byte attacker-controlled heap buffer overflow when a crafted regular expression containing an illegal user-defined Unicode property is compiled. The affected upstream range is Perl 5.30.0 through 5.38.0. Treat regular expressions supplied by an attacker as untrusted input, especially when an application compiles them rather than matching against a fixed pattern.

CVE-2023-47039 concerns Perl for Windows. Its path search for cmd.exe could look in the current working directory before the intended system location, allowing a malicious executable in a weakly protected location to run when an administrator launched a Windows-Perl program. This specific finding is not a Linux kernel or Linux path-search change, but it still matters if the same application or deployment process runs on Windows.

Do not try to reproduce either vulnerability on a production host. A clean regular-expression smoke test only checks that your interpreter can compile an ordinary pattern; it does not prove that a security fix is present:

$ perl -e 'my $re = qr/\p{IsGreek}/; print "regex compile ok\n"'
regex compile ok

4. Choose the upgrade action

If your package manager reports an older vulnerable Perl, schedule the vendor's supported update. Package updates can change the interpreter used by services, so identify consumers first:

$ rg -n '(^|[[:space:]/])perl([[:space:]]|$)' /etc/systemd /etc/cron* /usr/local/bin 2>/dev/null

The search is read-only and may report nothing. Also inspect service unit files and deployment manifests in their actual locations; do not assume every Perl process is started from /usr/local/bin. If a service will be restarted, use its maintenance window and keep the previous package and configuration rollback procedure available.

Updating packages is the point at which elevated privileges may be required. The exact command is distribution-specific, so use your configured security repository rather than pasting an unverified command. Do not remove the old interpreter by hand: another package or service may depend on it.

After the update, repeat the version checks and run the application's own test suite. A package update is not verified merely because perl -v prints a newer number; confirm the service is using the intended path and that its dependencies still load.

5. Handle common reading errors

• Confusing documentation with installation: perl5363delta reports changes; it does not select a package, patch a binary or restart a service.
• Checking only the major release: compare the full version, including the subversion and vendor package revision. A distributor can backport security patches without changing the upstream-looking version in the way you expect.
• Assuming Linux scope: the Windows binary-hijacking issue applies to Windows Perl. The Unicode-property issue concerns the interpreter and can affect more than one operating system.
• Testing only from your login shell: services and scheduled jobs can resolve a different interpreter. Check the executable in the unit, wrapper or container that actually runs the application.

There is nothing to undo from the read-only checks in this guide. If you changed packages, use the package manager's documented downgrade or rollback procedure and restore the service configuration only after confirming which version it requires.