Back to Blog

New Integer Overflow Bug Discovered in Solana rBPF

Code Auditing
December 30, 2021

Recently, our vulnerability detection system discovered a critical issue in the rBPF of Solana (i.e., the virtual machine where all the Solana dApps are running on: https://github.com/solana-labs/rbpf). After a careful investigation, we found that it is an integer overflow bug which can be exploited to crash down the whole Solana network. We have reported the bug to the Solana security team, and the team immediately sprang into action to confirm and fix the bug. As of this writing, almost all the validator nodes received the patch and upgraded to the latest version, which means it is safe to make a public disclosure.

eBPF and rBPF

Extended Berkeley Packet Filter (eBPF[1]) is initially developed for filtering packets in the kernel. Due to the security, efficiency, and scalability of eBPF, it is now used in various areas like networking, tracing, profiling, etc[2]. Considering the rich capability of eBPF, Solana choose it as the execution engine for the smart contract as well. To build the dApps on Solana, developers need to develop their smart contracts in Rust that will be compiled into eBPF bytecode.

To host the dApps of Solana, a precise virtual machine for eBPF is required. In this case, Solana uses the rBPF, which is a virtual machine for eBPF written in Rust. However, whether the proposed virtual machine (i.e., rBPF) is robust, secure, and precise is unknown. Once there exist security issues inside the rBPF, all the validators containing the rBPF can be influenced, resulting in huge loss (e.g., DDoS attack) for the whole Solana network.

The root cause of the bug

We have developed a tool to locate the bugs for the rBPF. This tool is still under the active development. During this process, one serious problem was identified in rBPF (version 0.2.16), which can take down the whole network.

Specifically, function “load” in file “elf.rs” is used to parse and verify the ELF file (the smart contract). First, function “load” would read the ELF structure and invoke function “relocate” to set up the callee offset. However, in function “relocate”, the attribute “sym.st_value” is retrieved from the ELF file directly . If the “st_value” is large enough, integer overflow could be triggered when calculating the “addr”, which is the sum-up of “sym.st_value” and “refd_pa”.

In this case, an attacker can create a malicious ELF file as a smart contract, which can trigger the integer overflow. After that, every validator would run the target ELF file and the rBPF would get panic with “add with overflow”.

At this moment, rBPF will get stuck and the coming transactions will not be executed, resulting in a DoS attack. We can observe that the node get stuck at “Finalizing transaction”, which is shown in the following, due to the integer overflow while loading the ELF file.

This issue was introduced in https://github.com/solana-labs/rbpf/pull/200, meaning the rBPF is vulnerable from version 0.2.14. We identified the issue and reported it to the Solana security team on 2021 December 6th. Solana fixes the issue in a few hours by using the safemath mechanism after our report. The fix is in https://github.com/solana-labs/rbpf/pull/236. At the time of writing (2021/12/30), more than 86% of the validators have upgraded to the newest version.

[1] https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

[2] https://ebpf.io/

Timeline

  • 2021/12/06: the problem was reported to the Solana security team
  • 2021/12/06: the vulnerability was fixed.
  • 2021/12/30: the information of this vulnerability was released
  • 2022/01/28: the CVE-2021–46102 was assigned
Sign up for the latest updates
~$800K Lost: Hinkal Double-Spend | BlockSec Weekly
Security Insights

~$800K Lost: Hinkal Double-Spend | BlockSec Weekly

This weekly security report covers 1 notable incident from June 29 to July 5, 2026, with approximately $800K in total losses on Ethereum. The Hinkal shielded-pool protocol was drained through a double-spend attack that likely exploited a flaw in the legacy note format, allowing the attacker to derive multiple nullifiers from a single deposit. The report analyzes the probable circuit-level vulnerability, the attack flow, and broader implications for nullifier-based privacy protocols.

Newsletter - June 2026
Security Insights

Newsletter - June 2026

This monthly report covers the three largest security incidents in June 2026, totaling approximately $22M in confirmed losses. A sophisticated honeypot attack drained ~$15M from JaredFromSubway's MEV bot by exploiting unchecked token allowances. Two legacy Aztec rollup deployments lost ~$4.35M through proof-settlement boundary gaps. SecondFi's Ed25519 implementation flaw exposed wallet private keys, resulting in ~$2.4M drained from 374 wallets. All three incidents share a common pattern: security guarantees that appeared intact on the surface but were never actually enforced.

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly
Security Insights

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly

This weekly blockchain security report covers two notable incidents from June 22-28, 2026, with approximately $4.1M in confirmed losses across Ethereum and Cardano. The Taiko bridge exploit combined an exposed SGX enclave signing key with an incomplete attestation policy that failed to reject debug enclaves, allowing the attacker to register a malicious prover and forge L2 state proofs on Ethereum. The SecondFi wallet vulnerability stemmed from a cryptographic implementation flaw in Ed25519 nonce derivation that removed the secret input, enabling offline private key recovery from public Cardano transaction data.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit