Skip to content

fix(api): guard nil AccountID in getAdditionalInfoStonfi (panic on addr_none pool tokens)#886

Open
kesha-antonov wants to merge 1 commit into
tonkeeper:masterfrom
kesha-antonov:fix-stonfi-nil-deref
Open

fix(api): guard nil AccountID in getAdditionalInfoStonfi (panic on addr_none pool tokens)#886
kesha-antonov wants to merge 1 commit into
tonkeeper:masterfrom
kesha-antonov:fix-stonfi-nil-deref

Conversation

@kesha-antonov

Copy link
Copy Markdown

What

getAdditionalInfoStonfi (pkg/api/emulation.go) panics with a nil-pointer
dereference when a STONfi pool's get_pool_data returns a token address of
addr_none (or addr_extern).

ton.AccountIDFromTlb returns (nil, nil) - a nil pointer and a nil error -
for AddrNone/AddrExtern, but the function only checks the error before
dereferencing the returned pointer:

t0, err0 := ton.AccountIDFromTlb(token0)
t1, err1 := ton.AccountIDFromTlb(token1)
if err1 != nil || err0 != nil {   // nil pointer not checked
    return
}
additionalInfo.STONfiPool = &core.STONfiPool{
    Token0: *t0,                  // panics if token0 == addr_none
    ...
    additionalInfo.SetJettonMaster(accountID, *master)  // panics if data.Jetton == addr_none

So emulating any trace that inspects such a contract panics the serving goroutine.

Why it's a clear bug, not an invariant

The NFT/jetton branch in the same function already guards exactly this pattern:

master, _ := ton.AccountIDFromTlb(data.Jetton)
if master == nil {
    continue
}

getAdditionalInfoStonfi simply omits the check on its three dereference sites.

Fix

Add the nil-pointer guards, mirroring the existing sibling branch (return early if
either token resolves to a nil AccountID; skip the jetton-master deref if it
does). One line per site, no behavior change for valid addresses.

Test

Adds TestStonfiNilAddressNoPanic (in pkg/api/): calls getAdditionalInfoStonfi
with addr_none token addresses and asserts it returns without panicking and
leaves STONfiPool unset. The test panics on the current code and passes with the
fix.

Reproduction (before the fix)

A get_pool_data (method id 81689) returning a STONfi-shaped stack whose
Token0Address/Token1Address slices hold the 2-bit addr_none prefix decodes
cleanly via abi.DecodeGetPoolData_StonfiResult and then panics in
getAdditionalInfoStonfi: runtime error: invalid memory address or nil pointer dereference at emulation.go:454.

ton.AccountIDFromTlb returns (nil, nil) for AddrNone/AddrExtern, but
getAdditionalInfoStonfi only checked the error before dereferencing the returned
pointer. A STONfi pool reporting an addr_none token address therefore panicked
the serving goroutine. Add the nil-pointer guards, mirroring the existing check
in the NFT/jetton branch, plus a regression test.
@mr-tron

mr-tron commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

lgtm

@Shemse1 Shemse1 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done ✔️

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.

3 participants