Skip to content

fix: validate libcef.so architecture after extraction on Linux#25

Open
c8dhjp4tyv-bit wants to merge 1 commit into
CCBlueX:1.21.11from
c8dhjp4tyv-bit:fix/linux-arm64-wrong-binary-architecture
Open

fix: validate libcef.so architecture after extraction on Linux#25
c8dhjp4tyv-bit wants to merge 1 commit into
CCBlueX:1.21.11from
c8dhjp4tyv-bit:fix/linux-arm64-wrong-binary-architecture

Conversation

@c8dhjp4tyv-bit

Copy link
Copy Markdown

On aarch64 systems, the linux_arm64/libcef.so served by CCBlueX's download server was found to be an x86_64 binary, causing an UnsatisfiedLinkError crash at startup (issue #8412).

This adds a post-extraction validation step that reads the ELF header of libcef.so and verifies the e_machine field matches the current platform architecture. If a mismatch is detected, a descriptive IOException is thrown instead of crashing with a cryptic UnsatisfiedLinkError deep in the JVM native loader.

Affected platforms: Linux ARM64 (e.g. Raspberry Pi 5)
ELF e_machine values: 0x3E = x86_64, 0xB7 = aarch64

On aarch64 systems, the linux_arm64/libcef.so served by CCBlueX's
download server was found to be an x86_64 binary, causing an
UnsatisfiedLinkError crash at startup (issue #8412).

This adds a post-extraction validation step that reads the ELF header
of libcef.so and verifies the e_machine field matches the current
platform architecture. If a mismatch is detected, a descriptive
IOException is thrown instead of crashing with a cryptic
UnsatisfiedLinkError deep in the JVM native loader.

Affected platforms: Linux ARM64 (e.g. Raspberry Pi 5)
ELF e_machine values: 0x3E = x86_64, 0xB7 = aarch64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant