CVE-2022-47696: Binutils objdump DoS crash from crafted files

Binutils’ objdump shipped a subtle but dangerous bug in its symbol-comparison routine that could be triggered by crafted object files to crash the tool and, in many real-world setups, take down services that rely on automated binary analysis.

Background / Overview​

The vulnerability tracked as CVE-2022-47696 affects the GNU Binutils collection’s objdump utility in releases before 2.39.3. In practical terms, a specially crafted object or executable file can cause a segmentation fault inside the compare_symbols routine used by objdump, producing a denial-of-service condition when the tool attempts to inspect or list symbols. The issue was publicly documented in the summer of 2023 and has since been addressed in fixed Binutils packages released by upstream and downstream distributors.
This is not a remote, unauthenticated network service vulnerability — the attack requires an attacker-supplied file to be parsed by objdump (or a service that invokes objdump on untrusted input). That said, the operational impact is broader than a single crashed command: many build systems, CI pipelines, automated analysis services, and malware/forensics tools call objdump on files gathered from untrusted sources. In those contexts, a crash can escalate into sustained or persistent loss of availability.

What went wrong: a technical primer​

At a technical level, the fault stems from unsafe assumptions about symbol data structures used by the Binary File Descriptor library (libbfd) and objdump’s symbol comparison logic. The compare_symbols function is responsible for ordering, comparing, or otherwise inspecting symbol table entries while objdump produces disassembly and symbol listings.

• In some code paths, fields that objdump expects to be initialized — notably internal BFD-related pointers attached to symbol structures — were either left uninitialized or could become NULL when presented with crafted or malformed files.
• When compare_symbols dereferences those fields without a defensive check, the process encounters a NULL pointer or other invalid memory reference and crashes with a segmentation fault.
• The resulting crash is a classic denial-of-service (DoS): objdump terminates and any process or pipeline depending on it fails.

While the underlying root causes are in C-level memory handling and insufficient defensive programming, the operational exposure depends on how and where objdump is run. It’s a local-file parsing vulnerability with user-triggered exploitation—an attacker must get a crafted file processed by a target system.

Severity and real-world impact​

• Attack vector: Local file input (attacker provides a malicious file).
• Privileges required: None on the target beyond the ability to convince a user or automated system to run objdump on the crafted file.
• User interaction: Required — objdump must be invoked on the file (directly by a user or by an automated process).
• Technical impact: Segmentation fault / crash of objdump; potential for wider availability impact on services.
• CVSS context: Public vulnerability assessments assigned this issue a high impact on availability and integrity in realistic setups where objdump is part of automated toolchains.

This combination yields practical attack scenarios far beyond a casual command-line crash. Consider these real-world examples:

• A continuous-integration (CI) environment that runs objdump on artifacts uploaded by developers or third-party dependencies; a crafted artifact could crash the analysis job and block the pipeline.
• Malware analysis sandboxes and automated triage systems that feed unknown binaries into objdump as part of a processing chain; mass ingestion of attacker-crafted files could exhaust worker nodes or force service restarts.
• Hosted code-repository features or web backends that generate symbol listings or disassembly previews for user-uploaded binaries; a crafted upload could repeatedly crash the preview service or require manual intervention.

In short, while the vulnerability is “local” in definition, the operational exposure is anything but limited when objdump is part of automated infrastructure that processes untrusted inputs.

Affected versions and fixes​

The vulnerability is present in Binutils objdump versions prior to 2.39.3. Upstream and major distributions have released fixes in their binutils packages; the practical guidance is simple:

• Upgrade to a patched Binutils package — either the upstream 2.39.3 (or later) release or the fixed version provided by your Linux distribution vendor.
• Distribution packaging names and version numbers may differ from upstream; always follow your OS vendor’s security advisory and install the vendor-supplied update rather than trying to deduce fixed versions across ecosystems.

Because many distributions patch and repackage Binutils independently, the specific fixed package version varies by distro and release. Operators should check their distribution’s security tracker or package manager for the binutils update that corresponds to the upstream fix and apply it promptly.

How attackers might exploit the bug (attack scenarios)​

While neither a remote wormable exploit nor a privilege-escalation vector, CVE-2022-47696 can be weaponized in multiple practical ways:

• Targeting automation: An attacker uploads a crafted binary to a service that automatically runs objdump (for metadata extraction, symbol analysis, or preview generation). The service crashes, causing denial-of-service to legitimate users.
• Supply-chain disruption: A maliciously crafted library or object file included in a dependency package triggers failures when developer machines or CI pipelines process the artifact, interrupting development workflows.
• Resource exhaustion: Repeatedly feeding crafted files into a pool of objdump workers can consume operator time and compute resources (restarts, debugging, reprocessing), multiplying the impact.
• Opportunistic interference: Threat actors targeting forensic or incident-response systems can intentionally cripple analysis tools by providing malformed samples, delaying defenders.

A crucial observation is that exploitation requires triggering objdump on attacker-controlled input — but that is trivially achievable against any code path that blindly runs objdump on user-supplied files. Because objdump is frequently used in automated environments, the barrier to exploit in the wild is low wherever such automation exists.

Detection, forensics and likely indicators​

Detecting exploitation of this class of vulnerability is primarily operational rather than signature-based. Look for:

• Repeated objdump process crashes or segfault logs in systemd, syslog, journald, or core dump locations.
• spikes in service restarts, CI job failures, or automated analysis task errors that correlate with ingestion of new or external artifacts.
• Core dumps that reference objdump or libbfd — these will contain stack traces pointing to compare_symbols or symbol-table routines.
• Audit logs showing large numbers of file uploads or file-processing tasks triggered by the same user account or IP around the time of the crashes.

Forensics notes:

• Core files can be analyzed with a safe offline debugging environment to confirm the crash stack trace and validate whether compare_symbols was involved.
• Preserve the offending file samples in an isolated environment for analysis, but avoid running objdump on production infrastructure until fixes or mitigations are in place.
• Consider replaying the exact ingestion path in a sandboxed environment to reproduce and validate the failure mode.

Mitigation and best practices​

Immediate steps that administrators and developers should take:

• Patch promptly. Install the vendor-supplied Binutils update that includes the fix for the compare_symbols crash. This is the single most effective mitigation.
• Harden ingestion pipelines. Avoid running objdump (or any native binary analysis tool) directly on untrusted files in the main service context. Instead:
• Process potentially malicious files in isolated sandboxes or containers with strict resource limits (cgroups, namespaces).
• Run analysis workers under unprivileged accounts with minimal filesystem access.
• Use ephemeral VMs or containers that are destroyed after processing.
• Add input validation and whitelisting. If your workflow only needs symbol data for known file types, validate file formats and reject or quarantine unexpected formats before invoking objdump.
• Rate-limit and isolate. Throttle the number of files a single user or IP can submit for analysis to reduce the impact of repeated crash attempts.
• Monitor and alert. Create alerts for unusual objdump failures, rise in core dumps, or abnormal CI job termination rates.
• Avoid trusting third-party artifacts. Treat dependencies, uploaded binaries, and out-of-band artifacts as untrusted; scan and vet them in isolation.

For enterprises, these mitigations should be combined with a broader approach to supply-chain hygiene and defensive programming — for example, verifying dependencies, adopting reproducible builds, and instrumenting CI to fail safely.

Developer guidance and long-term fixes​

The bug highlights recurring classes of risk in C-based systems tooling:

• Always initialize data structures. Uninitialized fields are a persistent root cause for unpredictable behavior. Enforce initialization patterns and lint/analysis tools to detect uninitialized members.
• Defensive programming. Before dereferencing internal pointers, check for NULL or otherwise invalid values; treat external input as untrusted.
• Fuzzing and targeted testing. Tools that parse complex binary formats benefit greatly from fuzz-testing and corpus-driven testing that includes malformed and edge-case files.
• Principle of least privilege. Tools that are used in automation should drop privileges as early as possible and run with minimal capabilities when operating on external inputs.
• Memory-safety transitions. Consider introducing safer parsing libraries or memory-safe components for parts of codebases where feasible to reduce the class of pointer-related bugs.

For maintainers of Binutils and libbfd, the recommended path is to harden symbol-table handling, audit similar code paths for uninitialized fields or missing NULL checks, and expand fuzz coverage on objdump and related tools.

Risk assessment and prioritization​

Assessing how urgent the fix needs to be in your environment depends on where objdump runs and what it processes:

• High priority: Public-facing services or automated infrastructures that accept user uploads or third-party binaries and immediately call objdump should patch immediately and apply sandboxing.
• Medium priority: Developer workstations and offline forensic tools — update when convenient, but prioritize CI and production services first.
• Lower priority: Air-gapped, manual-use-only tools with strict access control; still update at the next maintenance window, but the operational exposure is lower.

The risk is amplified where attackers can repeatedly supply crafted files to trigger crashes and impact availability. Even where exploitation is not aimed at exfiltration or arbitrary code execution, repeated denial-of-service can cause material business impact.

Related issues and context​

This vulnerability is one of several discovered in the Binutils toolchain over recent years that stem from libbfd’s complexity and broad format support. The library’s role — parsing many binary formats and symbol-table layouts — makes it a high-value, high-risk target for malformed-file attacks.
Administrators and security teams should view CVE-2022-47696 in the context of ongoing maintenance of native tooling: a single hardened library update or packaging fix can prevent many classes of DoS and parsing-driven failures across diverse toolchains.

Practical checklist for sysadmins and security teams​

• Identify where objdump is invoked automatically in your environment (CI, malware sandboxes, preview services).
• If found, prioritize patching those hosts with the Binutils update that includes the compare_symbols fix.
• Apply temporary mitigations (sandboxing, rate-limiting, quarantining uploads) if patching cannot be completed immediately.
• Enable monitoring and alerts for objdump crashes and abnormal job failures.
• Collect and isolate any suspicious files that cause crashes for offline analysis.
• Review build and analysis processes to minimize invocation of native parsing tools on untrusted data.

Conclusion​

CVE-2022-47696 is a reminder that even well-established toolchains like GNU Binutils can harbor subtle memory-safety problems with large operational consequences. Although the vulnerability requires a crafted file to trigger and is not remotely exploitable over the network on its own, the modern practice of automating binary analysis and symbol inspection makes this class of DoS both relevant and dangerous.
The path forward is straightforward and actionable: patch Binutils to a fixed release, harden ingestion and analysis pipelines, and treat any tool that parses untrusted binary input as a potential attack surface. For organizations that rely on automated processing of uploaded artifacts — from CI systems to malware sandboxes — converting those processes to sandboxed, least-privilege execution models will reduce the chance that a single crafted file can disrupt services or impede incident response.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center