Audit a Perl 5.38.2 Upgrade with perldelta

You will use the installed perldelta manual to establish which Perl release is present, read the changes from Perl 5.38.0 to 5.38.2, and record the two security issues named by that document. Allow about ten minutes for a single host. This is a review of release notes, not a package upgrade, and it does not replace your distribution's security advisory or test plan.

1. Check the installed Perl version

Start without elevated privileges. The local manual describes Perl 5.38.2, and this host has the matching interpreter and perl-doc package. Check the interpreter you will actually run, because a different shell path or service environment can select another installation.

$ command -v perl
/usr/bin/perl
$ perl -V:version
version='5.38.2';
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6

The first command reports the executable selected by your shell. The second asks that executable for its version. The third is Debian and Ubuntu specific, so it is useful evidence about the documentation package on this machine, not a portable way to identify Perl on every Linux system.

2. Read the release boundary before the details

Open the manual directly rather than searching for an option that perldelta does not have. It is a document installed with Perl, not a program that applies a patch or changes configuration.

$ man perldelta

The manual's name is "what is new for perl v5.38.2". Its stated comparison is 5.38.0 to 5.38.2, and it deliberately ignores 5.38.1. If you are coming from an earlier development or stable release, this page is only one part of the history. The manual specifically points readers upgrading from an earlier release such as 5.37.0 towards perl5380delta first.

That distinction prevents a common audit error: treating a delta document as a complete list of everything between your current version and the target. Write down both versions before deciding that the document covers your upgrade.

3. Review the security fixes

Find the Security section in the manual. Perl 5.38.2 records two issues.

• CVE-2023-47038 concerns a crafted regular expression using an illegal user-defined Unicode property. The affected range in the manual is Perl 5.30.0 through 5.38.0, with a one-byte attacker-controlled buffer overflow in a heap allocation.
• CVE-2023-47039 concerns Perl for Windows finding cmd.exe through the system path. The described path-search order can make a malicious executable in the current directory or another weakly protected location run when a more privileged user invokes a Windows Perl executable.

The second item is Windows-specific. It is still worth recording when you manage mixed fleets, but it is not evidence of a Linux kernel or Linux path-search vulnerability. The first issue concerns the Perl interpreter and regular-expression compilation, so it is relevant to Linux Perl services if their installed version falls in the stated range. Do not infer exploitability, exposure or remediation status solely from the presence of a package name.

4. Confirm the manual is the one you expect

Use the path and a small excerpt as an audit checkpoint. This does not change the system.

$ man -w perldelta
/usr/share/man/man1/perldelta.1.gz
$ man perldelta | col -b | sed -n '1,18p'
PERLDELTA(1)       Perl Programmers Reference Guide       PERLDELTA(1)

NAME
       perldelta - what is new for perl v5.38.2

DESCRIPTION
       This document describes differences between the 5.38.0 release and the
       5.38.2 release.

Your terminal may align the columns differently. The useful checks are the resolved manual path, the documented target version, and the comparison boundary. If man cannot find the page, install the documentation package through your normal distribution process or consult the package's official release notes. Do not copy a page from an unknown host into a system manual directory.

5. Turn the notes into an upgrade check

Before changing a production host, compare the result from step 1 with the version your package manager offers. Check the distribution changelog and security tracker as well, because distributors can backport a fix while retaining an older-looking upstream version. A version string alone cannot prove whether a vendor patch is present.

Keep the review unprivileged. Reading the manual and querying Perl do not require sudo. Installing or upgrading a package normally does, but that is a separate, service-affecting action. If you later upgrade a host, warn users, follow your maintenance process, preserve the package manager's transaction log, and test the applications that compile regular expressions or invoke Perl during deployment. Do not run a guessed command such as sudo apt upgrade perl merely because this manual names a CVE.

If an upgrade causes a regression, use your distribution's package-manager history and repository version to return to the previously approved package only under your normal rollback procedure. Keep the old package available until the application test has passed. A rollback can restore behaviour but also restore the security exposure, so record the decision and its expiry rather than treating it as a permanent fix.

6. Avoid the usual traps

• Wrong interpreter: perl -V:version checks the executable found by the current shell, not necessarily the interpreter used by a service.
• Incomplete history: 5.38.2's page starts at 5.38.0. Read the relevant earlier delta pages for a larger version jump.
• Platform mismatch: the cmd.exe issue is described for Windows Perl. Do not apply its threat model unchanged to Linux.
• False remediation: reading perldelta changes nothing. A fix requires a supported package or build, followed by testing and a controlled rollout.