fix: zero base token bytes before init to prevent IDL buffer attack

[ananas-block]

Summary

• Zero all 165 base token bytes before new_zero_copy initialization to prevent pre-set values (e.g. amount field via IDL buffer) from persisting, since new_zero_copy only writes mint, owner, and state.

[coderabbitai]

Warning

Rate limit exceeded

@ananas-block has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 3 minutes and 54 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

This change adds a pre-initialization step in the CToken account setup that zeros the first 165 bytes of token account data before zero-copy deserialization. This prevents unintended field values from the IDL buffer from persisting into the newly initialized state, ensuring a clean slate.

Changes

Cohort / File(s)	Summary
CToken Account Initialization programs/compressed-token/program/src/shared/initialize_ctoken_account.rs	Pre-initialization data zeroing of base token bytes (165 bytes) before new_zero_copy to prevent IDL buffer values from carrying into the new zero-copy state. Includes length validation check.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Possibly related PRs

• #1995: Addresses related CToken zero-copy initialization concerns by introducing checked zero-copy deserialization utilities to validate state and buffer length integrity.

Suggested labels

ai-review

Suggested reviewers

• sergeytimoshin
• SwenSchaeferjohann

Poem

🛡️ Hidden data ghosts no more,
Zeroed bytes, a cleaner door,
Before the copy, state runs true,
No IDL relics sneaking through! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main security fix: zeroing base token bytes before initialization to prevent an IDL buffer attack vulnerability.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 70.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/audit-issue-17-idl-buffer-token-init

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@programs/compressed-token/program/src/shared/initialize_ctoken_account.rs`:
- Around line 210-215: Replace the magic number 165 with a well-named constant
and fail on short buffers: add a new constant BASE_TOKEN_ACCOUNT_LEN: usize =
165 near the top of the file (alongside T22_ACCOUNT_TYPE_OFFSET) to document the
base SPL token account length, then change the zeroing block that currently
checks token_account_data.len() >= 165 to check token_account_data.len() >=
BASE_TOKEN_ACCOUNT_LEN and call
token_account_data[..BASE_TOKEN_ACCOUNT_LEN].fill(0); if the length is smaller
return an explicit error (propagate a suitable error/result from the surrounding
function) instead of silently skipping; keep references to token_account_data
and new_zero_copy intact.