Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Babylon Genesis Chain>Critical findings>Panic triggered by incorrect logic in finality module’s ,EndBlock
GeneralOverview
Findings
Critical (10)Nonce reuse in adaptor signatures allows recovering signing keyCosmWasm Stargate/Any messages bypass AnteHandler checksIncorrect parity check in adaptor signaturesPanic triggered by incorrect logic in finality module’s EndBlockSlashed finality provider retaining voting powerSlashed finality provider restoring voting power through pending delegationsArbitrary Deduction of Total Bond Satoshi from Unbonding Delegation HandlingThe btclightclient module design flaw after Babylon chain haltArbitrary Deduction of Total Bond Satoshi from Expiring Delegation HandlingIncorrect Delegation Status Check Leading to Chain Halt
High (4)
Medium (4)
Low (7)
Informational (7)
DiscussionBabylon node module-wise reviewed parametersDependency management and vulnerability assessmentPanic handling in ABCI++ handlersBehavior of MissedBlocksCounter on consecutive windows
DesignModule: btclightclientModule: btccheckpointModule: checkpointingModule: epochingModule: finalityModule: incentiveModule: monitorModule: mintModule: btcstakingbtc-stakerstaking-expiry-checkerbtc-staking-tsVigilante reporterVigilante submitterVigilante monitor (BTC timestamping monitor)Vigilante BTC staking trackerCryptographyFinality providerCovenant emulatorModule: staking-queue-clientstaking-api-servicebabylon-staking-indexersimple-staking
Audit ResultsAssessment Results
AddendumAddendumNonce reuse in adaptor signatures allows recovering signing key testsKey recovery succeeding on output from a btc-delegations query test
Category: Coding Mistakes

Panic triggered by incorrect logic in finality module’s EndBlock

Critical Severity
Critical Impact
High Likelihood

Description

A panic can occur due to incorrect logic in the BeginBlock and EndBlock functions of the finality module when the FinalitySigTimeout parameter is set to a value greater than zero. On the testnet, this parameter was observed to be set to 3.

The issue arises in a scenario where a finality provider (FP) is temporarily removed from the vote-disk cache due to insufficient voting power and then later reincluded after acquiring additional voting power. If the FinalitySigTimeout parameter is 3 and the block height is 5, the computation of heightToExamine results in 2. However, since the StartHeight for the re-added FP is set to 5, a panic is triggered when the condition↗ in liveness.go is evaluated.

Impact

This issue causes an unexpected node panic, disrupting block processing. If exploited intentionally or encountered in production, it could lead to network instability or downtime.

Recommendations

Modify the logic in liveness.go to ensure that the height condition does not cause unintended panics when an FP is re-added to the active set. A more precise condition should be implemented to handle cases where StartHeight is greater than heightToExamine, preventing invalid access to uninitialized data.

Remediation

This issue has been acknowledged by Babylon Labs, and a fix was implemented in commit 4b833eb7↗.

A fix was implemented to not cause a panic.

Zellic © 2025Back to top ↑