News

RustSec flags safe method unsoundness in solana_rbpf builtin call

RustSec flagged a safe solana_rbpf API that can push pointer math out of bounds before any builtin runs. The bug hits 0.8.0 through 0.8.5 and has no crate patch.

Jamie Taylor··2 min read
Published
Listen to this article0:00 min
RustSec flags safe method unsoundness in solana_rbpf builtin call
Source: defense.gov

RustSec’s June 29 advisory on solana_rbpf lands on a brutal Rust boundary: EbpfVm::invoke_function is a safe public method, yet it can still drive ptr::offset far outside the EbpfVm allocation before the builtin function is even called. That is the kind of failure that alarms Rust developers, because callers do not need unsafe code to cross into undefined behavior.

The advisory says the method builds an obfuscated VM pointer by casting self to *mut u64 and adding a randomized offset derived from get_runtime_environment_key(). It then uses ptr::offset, which only stays valid if the resulting pointer remains within the same allocation. In the vulnerable path, the offset can push the pointer well beyond the EbpfVm object, creating undefined behavior before the supplied builtin runs. OSV tracks the same issue and repeats the same root cause, making this an officially cataloged supply-chain vulnerability rather than a theoretical lint-level concern. RustSec classifies it as INFO unsoundness and tags it with memory-corruption keywords.

AI-generated illustration
AI-generated illustration

The affected range is 0.8.0 through 0.8.5. RustSec says there are no patched versions for solana_rbpf itself because the upstream solana-labs/rbpf repository has been archived. GitHub marks that repository as archived as of January 10, 2025, leaving the crate without a live maintenance path.

That matters because solana_rbpf sits in infrastructure used by Solana validators in user space. Docs.rs describes the crate as a virtual machine and JIT compiler for eBPF programs, and solana_program exposes cross-program invocations through invoke and invoke_signed, which makes this execution layer central to everyday Solana program flow. When a safe wrapper around VM state can still trigger undefined behavior, the abstraction boundary that Rust users rely on starts to look thinner than the type signature suggests.

The recommended path is to move to solana-sbpf, the maintained public fork in anza-xyz/sbpf, where the issue has already been fixed. Anza describes itself as the leading Solana-focused software development firm, and its fork now carries the work that solana_rbpf can no longer absorb. For anyone auditing security-critical VM code in Rust, this advisory is the reminder that safety depends on more than a safe method name: the pointer arithmetic underneath has to hold up too.

This article was produced by Prism’s automated news system from verified source data, official records, and press releases, then run through automated quality and moderation checks before publishing. The system is built and supervised by the people who set the standards it runs under. Read our full AI policy.

Did this article answer your question?

Discussion

More Rust Programming News