GNU Tar CVE-2022-48303: One-byte memory safety bug and its patch

GNU Tar’s handling of an old V7 archive format triggered a subtle memory-safety problem that quietly landed in the CVE lists: CVE-2022-48303 is a one‑byte out‑of‑bounds read in GNU Tar through version 1.34 that can cause use of uninitialized memory during a conditional jump — a bug that was fixed upstream but that left many Linux distributions and embedded products scrambling to roll out patches and advisories.

Background / Overview​

GNU Tar is one of the oldest and most widely deployed archive utilities in Unix‑like systems; it reads and writes many tar formats (including legacy V7 and modern PAX) and is embedded in countless distribution images, containers, and appliances. In early 2023 the issue tracked as CVE‑2022‑48303 was published: the vulnerable code lives in the from_header function in src/list.c and is triggered by a malformed V7 header where the mtime field contains roughly eleven whitespace characters. The specific failure mode is a one‑byte out‑of‑bounds read that makes a conditional branch depend on uninitialized memory.
The vulnerability’s public record is consistent on the basic facts: GNU Tar up to and including 1.34 is affected; the bug occurs when parsing certain V7 archives; and upstream addressed it in a commit that was folded into later releases. Distribution vendors (Ubuntu, Debian, SUSE, Red Hat family, Alpine and others) produced advisories and updated packages after the upstream fix.

---

What exactly went wrong? A technical breakdown​

The vulnerable path: from_header in list.c​

At its core the bug is not a dramatic heap spray or an obviously exploitable type confusion — it is a boundary‑check omission in a legacy code path that parses base‑256 encoded header fields for old tar formats. When handling certain header encodings the parser increments a pointer (the code variable conventionally named where) after reading the leading “marker” byte (values like 0x80 or 0xff), but then fails to re‑check that this pointer remains inside the 12‑byte field before continuing further reads. If the 12‑byte mtime field is crafted as 11 whitespace characters followed by a problematic lead byte, the pointer advances past the end-of-field and a subsequent read picks up an out‑of‑bounds byte — the program then performs a conditional jump based on that uninitialized value.

Why a single byte matters​

One‑byte out‑of‑bounds reads may appear trivial, but when they occur on CPU instructions that influence a conditional branch or move, the consequences can range from crashes (availability impact) to the theoretical possibility of changing control flow — and therefore, with enough favorable conditions, even remote code execution. In this case, publicly available analyses and canonical databases emphasize that exploitation to change flow of control has not been demonstrated, but they also note that conditional jumps on uninitialized memory are the kind of primitive that can, in some circumstances, be turned into more powerful primitives by an attacker. That duality — potential versus demonstrated capability — is central to assessing the real‑world risk.

---

Severity, CVSS and vendor scoring: the numbers disagree​

Different organizations assigned different scores and priorities to CVE‑2022‑48303, and those differences matter when you prioritize patching.

• NVD and many Linux vendors categorized the flaw as medium severity with a CVSS v3 base around 5.5, reflecting the local/user‑interaction vector and the current absence of demonstrated control‑flow exploitation.
• SUSE published a lower vendor score (around 4.3) in its tracking page, reflecting its internal threat model and product impact assessment.
• At least one vendor advisory (IBM’s advisory for certain products) referenced a higher 7.8 score from IBM X‑Force, a number that emphasizes a worst‑case impact (including confidentiality, integrity and availability impacts in some contexts). That higher score appears tied to vendor‑specific risk modelling for particular IBM products that embed tar.

Why the discrepancy? CVSS scoring is sensitive to assumed attack vector (local vs network), required user interaction, privileges, and whether a vendor believes evidence for information disclosure or code execution exists in their product context. The consensus among canonical sources is that the vulnerability is credible and fixed upstream, but variable scoring means organizations must consider their own exposure (for example, whether tar is used in an appliance or automated server process that may process untrusted archives).

---

Real‑world impact: what can an attacker actually do?​

The public advisory language is cautious: the upshot is that the practical impact depends heavily on the environment and how tar is invoked.

• Crash / Denial‑of‑Service: The simplest real‑world outcome is that a crafted archive causes tar to crash or hang, producing an availability impact. Several security scanners and IDS vendors treat the bug as a DoS risk.
• Memory corruption leading to code execution: Some advisories and third‑party bulletins treated the vulnerability as potentially leading to code execution if an exploit chain can be created (for example, IBM’s messaging around product impact noted a possible RCE vector), but upstream and NVD emphasize that altering control flow has not been demonstrated publicly. Where a vendor bundles tar into a larger product or runs tar with elevated privileges or in an unattended context, the practical risk increases. Flag and treat those cases differently from a desktop user running tar manually.

Put simply: the vulnerability can cause crashes and abnormal behavior when processing carefully crafted V7 archives; in the wild the path from that primitive to a reliable, remotely exploitable RCE is not publicly demonstrated, but some vendors and security services conservatively treat the worst‑case as plausible for specific product contexts.

---

What was the fix and where did it land?​

Upstream GNU Tar maintainers implemented a targeted fix that tightens bounds checking in the base‑256 decoding routine and ensures the 'where' pointer is validated after reading the lead byte. The patch was brought into later releases (Tar 1.35 and distribution‑specific backports), and many distributions released patched tar packages soon after. Packaging work and backports vary: Debian and Ubuntu included patched tar builds in their security updates; SUSE and Red Hat families shipped binary updates in their advisories; Alpine and others produced updated packages. The openembedded core repository and downstream packaging trees explicitly removed an interim CVE patch in favor of the integrated 1.35 upgrade.
Practical takeaways:

• If you run GNU Tar from upstream builds, upgrade to tar >= 1.35 (or the exact patched release your distribution provides).
• If you rely on distribution packages, apply your vendor’s security update (Ubuntu, Debian, SUSE, Red Hat family, Alpine, etc.). Distribution advisories list fixed package versions and CVE references.

---

Vendor advisories and distribution responses​

Linux distributions and product vendors followed a fairly standard path: identify the vulnerable versions, apply the upstream fix or backport the logic, then publish fixed package versions. Examples include:

• Ubuntu published status and fixed package versions for multiple releases (Jammy, Lunar, etc.). The public security page lists the change and the updated package numbers.
• Debian’s security tracker marked the CVE resolved for their packages and shows which releases received the backport.
• SUSE’s advisory describes the issue, the upstream reference and the package fixes for SLE and Leap.
• Red Hat / CentOS advisories and third‑party vulnerability trackers (Snyk, CVE Details) list the CVE and recommended patched packages.

If you manage heterogeneous infrastructure, consult your distro’s CVE page or package tracker and verify the exact fixed package version for each release you maintain.

---

Detection, IDS signatures and scanning guidance​

Because the bug is triggered by a crafted V7 header pattern, a few practical detection strategies exist:

• Network/IDS signatures: some vendors released IPS/IDS signatures that look for tar payloads with suspicious header patterns or the classic marker bytes that indicate the malformed base‑256 header. Juniper published a detection signature that flags attempts to exploit the from_header path. Use vendor signatures as part of perimeter defense but expect false positives and tuning needs.
• Host‑based scanning: vulnerability scanners (Tenable/Nessus, OpenVAS, distribution package trackers) will flag installed tar packages with the CVE. Regular vulnerability scanning is the fastest path to inventory which hosts are running an affected tar package.
• Behavioral detection: because exploitation may cause crashes or abnormal process termination, monitor for unexpected tar crashes in logging/observability data, particularly on file servers, CI/CD runners, container image builders, or appliances that automatically consume archives. Correlate unexpected tar terminations with incoming archive uploads to triage potential exploitation attempts.

---

Mitigations and hardening — immediate steps for admins​

If you are responsible for servers, build systems or appliances that use tar, apply the following prioritized checklist:

• Patch first:
• Update GNU Tar to the patched package your distribution provides (or upgrade to tar 1.35 if you build from upstream). Confirm package versions in your image/build pipelines.
• Reduce exposure:
• Avoid processing untrusted V7 tar archives. If you accept archive uploads, restrict accepted formats or re‑encode archives server‑side using safer libraries/tools before extraction.
• Run with least privilege:
• Never run tar as root on untrusted data. Prefer dedicated low‑privilege service accounts, chroot containers, or ephemeral sandboxes for archive processing. Containerize extraction workloads when feasible.
• Apply runtime restrictions:
• Use seccomp, AppArmor, SELinux or similar containment to limit what a process handling untrusted archives can do if compromised.
• Monitor and log:
• Add observability for tar invocations and failures, and correlate with file uploads or automation jobs. Unexpected crashes should be triaged promptly.
• Inventory and asset management:
• Identify all systems that have tar installed — this includes build hosts, CI runners, automated backup and restore jobs, container base images, and embedded appliances. Use package management queries and CMDB data.

---

Special considerations for embedded products, appliances and third‑party vendor stacks​

Many vendors embed GNU Tar into larger products — appliances, backup systems, middleware and bespoke Linux images. The security bulletin footprint for such vendors varies: some issued targeted advisories (IBM, appliance vendors), and product maintainers may need to apply the patch and reissue firmware or images. If you are a buyer or operator of such products, check vendor security pages and request proof of patching rather than assuming the vendor’s upstream dependency is patched in the product image. IBM explicitly called out products that required their internal remediation, underscoring how vendor‑specific risk can differ from distro expectations.
Because dependency inventories are often incomplete, treat vendor attestations conservatively: a vendor can accurately say that a product includes a vulnerable library, but confirming the absence of vulnerable artifacts across all product variants requires a full binary inventory review or attestations mapped to individual image builds. That inventory work is still a best practice for high‑assurance environments.

---

Threat model and likelihood: when to panic (and when not to)​

• Desktop users and occasional tar use: for most end users who invoke tar manually to pack or unpack archives, the immediate risk is low to medium — update when convenient but do not overreact. The public record emphasizes no demonstrated exploit chaining to reliable RCE.
• Servers that process untrusted archives automatically: moderate to high risk — these systems should be patched immediately and hardened because they receive untrusted inputs and may be invoked by automated services. Systems that extract archives as part of a public API should prioritize patching.
• Appliances, build servers, and vendor software that bundle tar: treat these as higher risk until you can confirm the vendor has issued patched firmware/images. Some vendor advisories described the vulnerability as potentially enabling RCE in a product‑specific context.

A word of caution: public exploit code was not available at disclosure, and many trackers list the EPSS (exploit prediction) percentile as very low — but that does not obviate business risk if your environment uses tar in privileged, unattended or network‑facing workflows.

---

For Windows users: where tar shows up and what to do​

Although GNU Tar is a Unix utility, Windows users can encounter tar in multiple ways:

• WSL / Windows Subsystem for Linux images include distro tar packages which inherit their distro CVE status. Patch those WSL distributions through the distro’s package manager.
• Cygwin or MSYS2 / Git for Windows bundles may include tar binaries — check the installed package versions and update via the platform’s package managers.
• Container images used on Windows hosts (via Docker/Podman) can include vulnerable tar binaries in their base images; rebuild or pull updated images.

If you don’t use tar directly on Windows but run Linux VMs, cts, those are the places to patch first.

---

Detection recipes and forensic tips​

If you suspect attempted exploitation or want to hunt proactively:

• Search logs for process crashes or core dumps of tar around times of file uploads or CI runs. Crashes that coincide with archive handling are high‑priority.
• Correlate auditd/ETW traces for tar execs with incoming network transfers or build artifact ingestion.
• On defenders’ side, sandbox suspicious archives first (inside ephemeral VMs) and instrument the extraction process to observe unexpected memory behavior.
• Preserve any suspicious archives and core dumps — they can be used to emulate in a controlled analysis environment and to share with vendors/response teams for root‑cause confirmation.

IDS rule matches (for example, the Juniper rule published for this signature) are a useful early warning but should be triaged — many archive transfer patterns are benign and require context.

---

What remains uncertain — and how we verified facts​

Several vendor pages and third‑party trackers offered different severity estimations and even different suggested impacts (some stated RCE potential more starkly than upstream sources). To be rigorous I cross‑checked canonical sources: the NVD/MITRE CVE record and the upstream GNU Savannah report describe the exact code path and the one‑byte out‑of‑bounds read; distribution trackers (Ubuntu, Debian, SUSE) documented the fixed package versions; and packaging trees and patch repositories (openembedded and distro advisories) show where the upstream fix was consumed. Where a vendor (for example, IBM) emphasized broader impact for specific product contexts, I flagged those vendor‑specific claims as product‑context assertions rather than universal facts.
For full transparency: community forum archives and internal thread indexes in operations teams show a steady stream of tar‑related posts around the disclosure window, highlighting how widely tar is embedded in infrastructure — those operational signals corroborate why organizations should treat this CVE as a priority for inventory and patching.

---

Final recommendations — an operational checklist​

• Inventory: find every host, container image, CI runner, appliance and build system that has tar installed. Prioritize systems that process untrusted archives.
• Patch: apply vendor‑supplied tar updates (or upgrade to tar 1.35 from upstream) and rebuild images where necessary.
• Harden: run archive extraction under least privilege, in sandboxes, or in ephemeral containers. Limit what the extraction process can do if it is compromised.
• Monitor: add observability for tar crashes, and deploy IDS/IPS rules in perimeter systems where archive upload abuse is plausible.
• Vendor follow‑up: ask appliance and product vendors for signed attestations or fixed firmware builds if their products embed tar. Don’t assume a vendor‑supplied attestation applies to all images or branches unless explicitly stated.

---

CVE‑2022‑48303 is a reminder that legacy file formats and long‑standing utilities still carry memory‑safety risk. The technical flaw is narrow, the upstream fix is narrow and surgical, and distribution vendors have already moved to ship updates. Nevertheless, the operational reality — countless images, embedded devices and unattended archive consumers — means the hard work of inventory, patching, containment and observability still matters. Apply updates, harden archive processing, and prioritize the systems that routinely ingest untrusted archives. The fix exists; the job now is to ensure it reached every system that needed it.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center