The Bug

The newly introduced resolveBlockNumForRangeCheck function (api.go:65-75) is responsible for converting symbolic block numbers into concrete heights for the range limit guard. However, it does not match the actual resolution behavior in filter.go:resolveSpecial (lines 104-137), leading to two distinct issues:

1. Range limit bypass via finalized/safe sentinels

resolveBlockNumForRangeCheck maps FinalizedBlockNumber (-3) and SafeBlockNumber (-4) to head (line 74), treating them identically to LatestBlockNumber. However, the actual filter execution in resolveSpecial resolves these to their real block heights by calling HeaderByNumber(ctx, rpc.FinalizedBlockNumber) (line 113) and HeaderByNumber(ctx, rpc.SafeBlockNumber) (line 119), which can return values significantly behind head.

Step-by-step proof:

1. Node has head at block 10000, finalized at block 9500, --rpc.rangelimit set to 100.
2. User calls eth_getLogs with fromBlock: "finalized", toBlock: "latest".
3. checkBlockRangeLimit calls resolveBlockNumForRangeCheck(-3, 10000) which returns 10000 (head), and resolveBlockNumForRangeCheck(-2, 10000) which also returns 10000.
4. The computed range = 10000 - 10000 = 0, which is <= 100, so the check passes.
5. The actual filter in resolveSpecial resolves finalized to 9500 (via HeaderByNumber) and latest to MaxUint64 (which maps to head=10000 during iteration).
6. The filter scans blocks 9500-10000 = 500 blocks, which is 5x the configured 100-block limit.

On Polygon/Bor specifically, the finalized block can lag significantly behind head due to Heimdall milestone/checkpoint delays. This completely defeats the purpose of --rpc.rangelimit, which exists to protect RPC nodes from expensive wide-range log queries.

2. False rejection of earliest-based queries on pruned nodes (minor)

resolveBlockNumForRangeCheck maps EarliestBlockNumber (-5) to 0 (line 71-72). However, resolveSpecial maps it to HistoryPruningCutoff() (line 125), which on pruned nodes can be much higher than 0.

Step-by-step proof:

1. Node is pruned with HistoryPruningCutoff = 74995000, head = 75000000, --rpc.rangelimit = 10000.
2. User calls eth_getLogs with fromBlock: "earliest", toBlock: "latest".
3. Range check resolves earliest to 0, latest to 75000000. Range = 75000000 > 10000 → REJECTED.
4. Note: The HistoryPruningCutoff guard at api.go line 523 is skipped because begin = -5 fails the begin >= 0 check.
5. But the actual filter resolves earliest to 74995000 and latest to head (75000000), scanning only 5000 blocks — well within the 10000 limit.
6. A valid query is wrongly rejected.

This second issue is less severe (false rejection is conservative/safe, and users can work around it with concrete block numbers), but both stem from the same root cause.

Fix

resolveBlockNumForRangeCheck should resolve finalized/safe to their actual block heights via HeaderByNumber (or accept pre-resolved values), and resolve earliest to HistoryPruningCutoff() instead of 0. This requires the function to have access to the backend, so the signature would need to change.

What the bug is

In cmd/utils/flags.go:RegisterFilterAPI (lines 2241-2254), two separate filters.NewFilterAPI instances are created:

1. Line 2247: filterAPI := filters.NewFilterAPI(filterSystem, ethcfg.BorLogs) — stored in a local variable
2. Line 2250: Service: filters.NewFilterAPI(filterSystem, ethcfg.BorLogs) — a completely different instance, registered with stack.RegisterAPIs

Then on line 2254, filterAPI.SetChainConfig(ethcfg.Genesis.Config) is called on instance #1 (the local variable). Instance #2 (the one actually serving RPC requests) never receives SetChainConfig, so its chainConfig field remains nil.

How it manifests

In eth/filters/bor_api.go:GetBorBlockLogs (line 19), the very first check is:

if api.chainConfig == nil {
    return nil, errors.New("no chain config found. Proper PublicFilterAPI initialization required")
}

Since the registered instance has chainConfig == nil, every bor_getLogs RPC call through the cmd/geth path will immediately return this error. The bor_getLogs endpoint is effectively broken for nodes started via the cmd/geth entry point.

Step-by-step proof

1. User starts a node using cmd/geth (which calls RegisterFilterAPI)
2. RegisterFilterAPI creates filterAPI (instance MAT-156 Span sync #1) at line 2247
3. At line 2250, a new filters.NewFilterAPI(filterSystem, ethcfg.BorLogs) call creates instance build(deps): bump mixin-deep from 1.3.1 to 1.3.2 in /dashboard/assets #2 and registers it as the eth namespace RPC service
4. filterAPI.SetChainConfig(ethcfg.Genesis.Config) at line 2254 sets chain config on instance MAT-156 Span sync #1
5. Instance MAT-156 Span sync #1 (filterAPI) is never used again — it is not returned, stored, or referenced
6. A bor_getLogs RPC request arrives and is routed to instance build(deps): bump mixin-deep from 1.3.1 to 1.3.2 in /dashboard/assets #2
7. Instance build(deps): bump mixin-deep from 1.3.1 to 1.3.2 in /dashboard/assets #2 checks api.chainConfig == nil → true → returns error

Why existing code does not prevent it

The eth/backend.go path (used by the internal/cli/server entry point) does this correctly — it creates a single publicFilterAPI instance, calls SetChainConfig on it, and registers that same instance. However, the cmd/utils/flags.go path has this copy-paste-style duplication that was never caught.

Impact

Any Bor node started via the cmd/geth binary that receives a bor_getLogs RPC call will get an error response. The eth_getLogs path is unaffected since it does not check chainConfig. The internal/cli/server path (the primary Bor CLI) also correctly wires a single instance in eth/backend.go, so this bug primarily affects the legacy cmd/geth entry point.

How to fix

Replace the filters.NewFilterAPI(filterSystem, ethcfg.BorLogs) on line 2250 with the existing filterAPI variable:

stack.RegisterAPIs([]rpc.API{{
    Namespace: "eth",
    Service:   filterAPI,
}})

This ensures the same instance that receives SetChainConfig is the one serving RPC requests, matching the pattern already used in eth/backend.go.

What is missing

GetLogs in api.go (lines 476-490) performs three validations before constructing a filter:

1. len(crit.Topics) > maxTopics — rejects queries with more than 4 topic positions
2. logQueryLimit check — rejects queries where len(crit.Addresses) or any len(topics) per position exceeds the configured limit
3. HistoryPruningCutoff check (line 523) — returns PrunedHistoryError if begin is before the pruning cutoff

GetBorBlockLogs in bor_api.go has none of these. The PR adds begin > end validation and checkBlockRangeLimit (lines 42-48) but does not add the other three checks.

Step-by-step proof

Consider a node with --rpc.logquerylimit 1000 and --bor.logs enabled:

1. A caller sends eth_getLogs with 2000 addresses → rejected at api.go:482 with errExceedLogQueryLimit.
2. The same caller sends bor_getLogs with 2000 addresses → passes all validation in bor_api.go, reaches NewBorBlockLogsRangeFilter, and the filter iterates every block in the range performing in-memory log matching against all 2000 addresses.

For HistoryPruningCutoff: if a node has pruned history below block 1,000,000 and a caller queries bor_getLogs with fromBlock=0, GetLogs would return PrunedHistoryError at line 523, but GetBorBlockLogs proceeds. BorBlockLogsFilter.unindexedLogs calls HeaderByNumber which returns nil for pruned blocks, causing the filter to silently return empty/partial results rather than a clear error.

Practical impact

The practical impact is low for several reasons:

• maxTopics: EVM only supports LOG0-LOG4, so >4 topic criteria would match nothing. Still a consistency issue.
• logQueryLimit: BorBlockLogsFilter uses simple linear block iteration (not the filtermaps index), so the cost scales linearly rather than triggering expensive index queries. The block range limit (now enforced) is the primary DoS vector.
• HistoryPruningCutoff: The filter handles pruned blocks gracefully (no crash or data corruption), but users get silently empty results instead of an informative error.
• bor_getLogs scope: This endpoint only covers pre-Madhugiri (PIP-74) blocks (bor_filter.go:105), further limiting the attack surface.

Why this is pre-existing

These checks were never present in GetBorBlockLogs. The PR does not introduce the gap — it adds range limit and begin > end checks while missing the opportunity to also add maxTopics, logQueryLimit, and HistoryPruningCutoff for consistency.

Suggested fix

Add the following at the top of GetBorBlockLogs, mirroring GetLogs:

if len(crit.Topics) > maxTopics {
    return nil, errExceedMaxTopics
}
if api.logQueryLimit != 0 {
    if len(crit.Addresses) > api.logQueryLimit {
        return nil, errExceedLogQueryLimit
    }
    for _, topics := range crit.Topics {
        if len(topics) > api.logQueryLimit {
            return nil, errExceedLogQueryLimit
        }
    }
}

And in the range branch, before constructing the filter:

if begin >= 0 && begin < int64(api.events.backend.HistoryPruningCutoff()) {
    return nil, &history.PrunedHistoryError{}
}