CVE-2017-9756

This bug is like a “bad file that breaks the viewer.” If someone gives you a specially crafted binary and you ask objdump -D to disassemble it, Binutils 2.28 can crash while reading certain ARM64 instruction patterns. For a business, the most likely outcome is your analysis tool stops working at that moment, interrupting workflows and potentially impacting how you handle incoming files.

This matters to you if your business uses GNU Binutils—specifically objdump -D—on ARM64/aarch64 binaries while running GNU Binutils 2.28. It’s not about normal users browsing the web; it’s about parsing a crafted file you (or your automated process) open or analyze. The risk exists only when the crafted binary is provided to the tool in a way that objdump -D processes it (i.e., you run the command against untrusted input on a system running GNU Binutils 2.28).

Attackers have a publicly available example that can trigger the crash, and the likelihood trend is rising. Because exploitation is tied to analyzing a crafted binary file, this is most urgent for businesses that regularly process untrusted executables. With an AMBER verdict, you should schedule an upgrade promptly and avoid running the affected command on untrusted samples in your production environment.

1. Confirm exposure

   • Determine the exact Binutils version installed on systems that run objdump (look for GNU Binutils 2.28).
   • Confirm whether those systems are used to run objdump -D on ARM64/aarch64 binaries (including samples received from outside your organization).

2. Check your process for untrusted input

   • Enumerate sources of binaries you analyze: downloaded files, customer uploads, email attachments, third-party integrations, malware-analysis pipelines, shared repositories.
   • Pay special attention to automated jobs that disassemble files without validation.

3. Upgrade remediation (preferred)

   • Upgrade GNU Binutils from 2.28 to the fixed release that incorporates the fix tracked under Sourceware Bugzilla 21595.
   • After upgrading, re-test your usual disassembly workflow (your same objdump -D commands on representative ARM64 inputs).

4. Temporary workaround (if you cannot upgrade immediately)

   • Stop running objdump -D on untrusted binaries on your main environment.
   • Run disassembly in an isolated environment (separate machine, disposable VM, or tightly contained container) with limited access to the rest of your systems.

5. What to monitor

   • Monitor your systems for unexpected objdump/Binutils crashes during disassembly jobs.
   • If you have CI or automation that disassembles incoming binaries, track job failures and correlate them with the input file source/time.

6. CISA KEV status

   • This CVE is not listed in the CISA KEV catalog (so focus on your own exposure and your untrusted-file handling).

CVE-2017-9756 describes a memory handling flaw (CWE-119) in aarch64_ext_ldst_reglist within opcodes/aarch64-dis.c for GNU Binutils 2.28. The trigger is processing a crafted executable during disassembly with objdump -D, where a buffer overflow can occur, leading to a denial of service (application crash). Findings indicate a public exploit is available (at least one known), but KEV does not list this issue, and the exact fixed version number is not provided in the supplied findings—only the Sourceware Bugzilla entry (21595). The workload impact is primarily operational (crashing the tool) rather than ongoing compromise, and exploitation requires the attacker-controlled crafted binary to be fed into the disassembler running the vulnerable version. Publicly visible exploit/demo presence and rising attention/press increase concern, and the overall verdict for this CVE is AMBER.