Out-of-bounds read past end of 1 GiB mapping on CPUs without AVX/SSE4 (SIGSEGV, not SIGILL)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: this report started as an AVX-compatibility issue. A gdb session on the affected machine showed the actual fault is an out-of-bounds read at a mapping boundary, not an illegal instruction. The analysis is in the comments below; this body has been updated to match. The title was changed accordingly.

Claude Code 2.x crashes on startup on x86-64 machines whose CPU does not expose AVX/SSE4. Both distribution channels fail identically:

• curl -fsSL https://claude.ai/install.sh | bash
• npm install -g @anthropic-ai/claude-code

Bun v1.3.14 (521eedd6) Linux x64 (baseline)
Linux Kernel v6.11.4 | glibc v2.40
Args: "/home/zdavatz/.claude/downloads/claude-2.1.150-linux-x64" "install"
Features: jsc no_avx2 no_avx standalone_executable claude_code

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x43AE6000000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

bash: line 151: 1224993 Illegal instruction  "$binary_path" install ${TARGET:+"$TARGET"}

This follows up on #62283, which was closed as duplicate without a fix.

Root cause (details in the comments)

Under gdb the process dies with SIGSEGV, not SIGILL. The faulting instruction is a plain scalar 4-byte load:

=> 0x2ae1140:   mov    (%rax),%ecx
   0x2ae1145:   cmp    $0xc2,%cl

%rax is 0x3580afffffd; si_addr is 0x3580b000000, which is exactly the end of a 1 GiB anonymous mapping. The 4-byte load starts three bytes before that end and its last byte falls into a 4 MiB unmapped gap. This is an out-of-bounds read of up to 3 bytes past the end of a mapping, in what looks like a UTF-8 decoder (0xC2 is the lowest valid two-byte lead byte).

On most systems something is mapped after the buffer and the overread is harmless. Here the allocation sits flush against the region end, so it faults.

Why the CPU still appears to matter

Stated as a hypothesis, since I cannot see the symbols: if the decoder selects a vectorised path at runtime based on CPU features, machines without AVX/SSE4 fall back to this scalar dword-at-a-time path. That fallback would be exercised far less in testing, which would explain why the defect survives on modern hardware. Someone with the debug build can confirm or rule this out quickly.

The panic message is misleading

CPU lacks AVX support. Please consider upgrading to a newer CPU. appears to be a generic line printed whenever Bun panics on a machine without AVX, not the result of diagnosing the actual fault. It sends affected users after a hardware upgrade that would not fix the underlying defect.

Exact ISA boundary on the affected machine

From /proc/cpuinfo: sse, sse2, pni (SSE3) and cx16 are present. Missing: SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2. So the guest is pre-SSSE3, not merely pre-AVX.

The hosting provider cannot fix this

I asked my provider (nine.ch) to switch the VM to host-passthrough or any CPU model exposing AVX. Their answer: this generation of root servers runs on an older virtualization platform that cannot expose those flags at all. The only remedy they offer is migrating to a different product.

The physical host almost certainly has AVX — the hypervisor does not pass it through, and the customer has no control over that. "Upgrade your CPU" is not actionable for users on managed or legacy hosting.

What Should Happen?

1. Fix the overread: bound the read to the remaining buffer length, or ensure the decoder never reads past the end of its allocation. This is the actual defect and would fix the crash regardless of CPU.
2. Replace the panic message with something accurate. If a CPU feature check is genuinely needed, run it early and exit cleanly; if the crash is unrelated to AVX, stop pointing users at their hardware.
3. Consider keeping a pure-Node variant published for environments where the native binary cannot run: legacy VMs, restricted corporate fleets, older hardware still in production.

Error Messages/Logs

Setting up Claude Code...
============================================================
Bun v1.3.14 (521eedd6) Linux x64 (baseline)
Linux Kernel v6.11.4 | glibc v2.40
Args: "/home/zdavatz/.claude/downloads/claude-2.1.150-linux-x64" "install"
Features: jsc no_avx2 no_avx standalone_executable claude_code
Builtins: "bun:main"
Elapsed: 27608ms | User: 18240ms | Sys: 9368ms
RSS: 7.96GB | Peak: 4.03GB | Commit: 7.96GB | Faults: 0 | Machine: 25.20GB

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x43AE6000000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

https://bun.report/1.3.14/B_1521eeddkggggEggggigD4wvo4E+x+Pgm5qyCm2n89Cmt169C+sz2pD6vzqkEo6v+iE+yxh0F+luh0Fmqv7wF0s41tEkltz6Cgz+g1Cw1lqxCmg+2tEsk04wCy5/qpC6z0qpCA20jChgggga

bash: line 151: 1224993 Illegal instruction   "$binary_path" install ${TARGET:+"$TARGET"}

Steps to Reproduce

On affected hardware

Any x86-64 machine or VM without AVX/SSE4. Mine reports:

model name      : QEMU Virtual CPU version 2.5+
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
                  pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl
                  cpuid tsc_known_freq pni cx16 x2apic hypervisor lahf_lm pti

Then run either installer. Both crash immediately.

Without affected hardware — qemu user-mode emulation

sudo apt install qemu-user
qemu-x86_64 -cpu qemu64,-ssse3,-sse4.1,-sse4.2,-popcnt,-avx,-avx2 \
  ~/.local/bin/claude --version     # expect a crash
qemu-x86_64 -cpu Haswell ~/.local/bin/claude --version   # expect success

Caveat: emulation may not reproduce the exact allocation layout that puts the buffer flush against a mapping end, so a clean run here does not disprove the bug.

Full VM

qemu-system-x86_64 -cpu qemu64 -m 4096 -smp 2 \
  -drive file=ubuntu-24.04-server-cloudimg-amd64.img,format=qcow2

Environment is not the cause

$ ulimit -v
unlimited
$ cat /proc/sys/vm/max_map_count
65530
$ cat /proc/sys/vm/overcommit_memory
0

No address-space limit, default overcommit heuristics, default map count with only a few dozen mappings in use. The allocation succeeded; the read runs past its end.

Workaround

npm install -g @anthropic-ai/claude-code@1.0.120 runs correctly on this machine. That version still ships as a single ~9 MB cli.js — pure Node, no native binary.

I have confirmed 1.0.120 works but have not bisected the exact last working version. The break is structural rather than gradual: from 2.x onward the npm package is a thin wrapper whose bin/claude.exe is a ~238 MB single-file executable, pulled in through platform-specific optionalDependencies and copied into place by install.cjs at postinstall. Any 1.x should work and any 2.x should fail, but I have only verified the two endpoints.

Auto-update must be disabled afterwards (claude config set -g autoUpdates false), otherwise claude update silently pulls 2.x back in and the CLI stops working again with no explanation.

Is this a regression?

Yes.

Last Working Version

1.0.120 (confirmed working; exact boundary not bisected)

Claude Code Version

2.1.150 (fails)

Platform

Native binary installer (claude.ai/install.sh) and npm — both affected

Operating System

Ubuntu/Debian Linux, kernel 6.11.4, glibc 2.40

Terminal/Shell

bash / xterm

Additional Information

I still have the affected machine and can run further diagnostics, provide a fuller mapping dump, or test a candidate build on request.