jdx/mise · error · eyre::Report

unsupported ELF byte order

Error message

unsupported ELF byte order

What it means

Thrown by elf_interpreter when the ELF EI_DATA byte (byte 5) is neither 1 (little-endian) nor 2 (big-endian). Real Linux executables are always one of these, so a different value indicates a corrupted, truncated, or deliberately malformed ELF header rather than any platform mismatch.

Source

Thrown at src/system/remote.rs:1364

        if bytes.get(offset) != Some(&b'.') {
            break;
        }
        offset += 1;
    }
    (!components.is_empty()).then_some(AbiVersion(components))
}

fn elf_interpreter(bytes: &[u8]) -> Result<Option<String>> {
    const ELF_MAGIC: &[u8] = b"\x7fELF";
    const PT_INTERP: u64 = 3;
    if !bytes.starts_with(ELF_MAGIC) {
        bail!("local mise is not an ELF executable");
    }
    let class = *bytes.get(4).ok_or_else(|| eyre!("truncated ELF header"))?;
    let little_endian = match bytes.get(5) {
        Some(1) => true,
        Some(2) => false,
        _ => bail!("unsupported ELF byte order"),
    };
    let (program_offset, entry_size, entry_count, offset_field, size_field) = match class {
        1 => (
            read_elf_int(bytes, 28, 4, little_endian)?,
            read_elf_int(bytes, 42, 2, little_endian)?,
            read_elf_int(bytes, 44, 2, little_endian)?,
            4,
            16,
        ),
        2 => (
            read_elf_int(bytes, 32, 8, little_endian)?,
            read_elf_int(bytes, 54, 2, little_endian)?,
            read_elf_int(bytes, 56, 2, little_endian)?,
            8,
            32,
        ),
        _ => bail!("unsupported ELF class"),
    };

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. Restore the binary from a trusted source and re-run (verify with: file mise && readelf -h mise | grep -i 'data encoding')
2. If it is a build artifact, rebuild it and check the toolchain output
3. Fall back to bootstrap_command/remote_mise so the local binary is not parsed at all

Example fix

# verify and replace a corrupted binary
file ./mise           # before: data encoding: corrupt/unexpected

curl -fsSL https://mise.run | sh  # reinstall official binary
file ~/.local/bin/mise # after: ELF 64-bit LSB executable

// Reject corrupt ELF headers before upload validation
fn elf_header_sane(path: &Path) -> bool {
    let mut magic = [0u8; 6];
    let Ok(mut f) = std::fs::File::open(path) else { return false };
    std::io::Read::read_exact(&mut f, &mut magic).is_ok()
        && &magic[..4] == b"\x7fELF"
        && matches!(magic[4], 1 | 2)   // class
        && matches!(magic[5], 1 | 2)   // data encoding
}

fn elf_header_sane(path: &Path) -> bool {
    let mut magic = [0u8; 6];
    let Ok(mut f) = std::fs::File::open(path) else { return false };
    std::io::Read::read_exact(&mut f, &mut magic).is_ok()
        && &magic[..4] == b"\x7fELF"
        && matches!(magic[4], 1 | 2)
        && matches!(magic[5], 1 | 2)
}

match elf_interpreter(&bytes) {
    Err(e) if e.to_string().contains("unsupported ELF byte order") => {
        // header corruption: restore from trusted source instead of parsing further
        eyre::bail!("mise binary at {} has a corrupt ELF header; re-download or rebuild", path.display());
    }
    other => other?,
}

When it happens

Trigger: The mise_bin file's header is damaged (bit rot, interrupted copy, tool that rewrote the header) while validating Linux-to-Linux upload compatibility.

Common situations: Interrupted downloads; files mangled by transfer modes (e.g. ASCII-mode FTP); fuzzed or hand-crafted binaries reaching the validation path.

Related errors

• unsupported ELF class
• local mise is not an ELF executable
• trimPrefix requires exactly 2 arguments
• trimSuffix requires exactly 2 arguments
• action prediction payload is too large

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/b051b6f876d373f7. Report an issue: GitHub.